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THE  THIRD  TECHNICAL  FORUM 


ON  THE 

F-1  6  MIL-STD-1 750A  MICROPROCESSOR 
AND  THE 

F-1 6  MIL-STD-1 589B  COMPILER 


1.  Welcome  to  Dayton,  Ohio,  the  home  of  the  F-16  System  Program  Office  (SPO) 
and  the  Air  Force  Museum.  My  name  is  Jeff  Pesler  and  I  will  be  your  host  for 
the  next  two  days.  This  is  the  third  in  a  series  of  technical  forums  sponsored 
by  the  F-16  SPO.  The  purpose  of  these  forums  is  to  keep  you  -  the  user 
community  -  informed  about  new  developments  in  the  F-16  embedded  computer 
standardization  program.  The  first  Technical  Forum  was  held  in  May  of  1981.  It 
was  for  "government  only"  and  there  were  only  thirty  attendees.  The  second,  in 
October,  grew  to  seventy  and  then  the  October  presentation  was  taken  public  at 
the  4th  Digital  Avionic  Systems  Conference  in  November.  Ninety  attendees  came 
to  the  tutorial  session  and  over  two  hundred  were  at  the  forum  that  followed. 
Today  over  two  hundred  fifty  people  are  expected  at  the  Third  Technical  Forum. 

As  you  can  see,  there  is  a  large  interest  in  our  program  and  we  have  grown 
considerably. 

2.  I  hope  you  will  enjoy  and  benefit  from  the  presentations  over  the  next  two 
days.  Every  effort  was  made  to  assemble  material  on  the  F-16  Standardization 
Program  that  would  be  useful  to  others.  The  General  Dynamics  and  Fairchild 
briefings  will  contain  in  depth  technical  and  management  details  on  the  F-16 
microprocessor  and  compiler  development  programs.  On  the  second  day,  papers  on 
other  on-going  standardization  efforts  will  be  presented.  Thank  you  again  for 
your  participation  and  interest  in  the  F-16  program. 

JEFFERY  L.  PESLER 
Project  Engineer 
Deputy  for  F-16 
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STANDARDIZATION  INITIATIVES  TO  REDUCE  SOFTWARE  COSTS 


By  D.  Burton  Newlin,  Jr. 

Office  of  the  Under  Secretary  of  Defense  (Research  and  Engineering) 
Defense  Materiel  Specifications  and  Standards  Office 


The  Department  of  Defense  has  become  increasingly  dependent  on  computer 
technology  to  accomplish  its  mission.  Computer  costs  are  consuming  an  ever 
increasing  percentage  of  the  CoD's  budget.  Within  the  DoD  the  majority  of 
the  computers  are  embedded  within  weapon  systems  to  perform  command  and  con¬ 
trol,  communications,  navigation,  surveillance,  target  detection  intelligence 
and  other  functions  critical  to  their  strategic  and  tactical  missions.  With 
the  accelerating  advances  in  electronic  technology  hardware  has  become  rela¬ 
tively  inexpensive,  and  the  development  of  microprocessors  and  microcomputers 
have  permitted  substantial  increases  in  both  the  amount  of  main  storage  which 
could  be  supported  and  the  associated  software  to  be  written.  As  a  result 
the  majority  of  DoD* s  computer  resources  now  involve  the  computer  software 
associated  with  weapon  systems. 

Management  attention  has  been  directed  towards  standardization  as  one 
approach  to  control  and  reduce  these  software  costs.  The  two  major  efforts 
towards  standardization  involve  the  development  of  a  common  high  order  pro¬ 
gramming  language  and  the  development  of  a  limited  number  of  instruction  set 
architectures  for  computer  software  applications  embedded  within  defense 
systems. 

Increased  Management  Attention 

Legislative  changes  to  the  computer  acquisition  process  have  increased 
the  emphasis  management  must  place  on  DoD* s  Mission  Critical  Computer 
Resources.  Recent  OSD  internal  organizational  changes  have  further  empha¬ 
sized  the  importance  of  software  management  and  need  to  strengthen  the 
decision-making  management  organization  to  oversee  defense-wide  standardiza¬ 
tion  efforts.  Dr.  Edith  Martin  has  been  recently  appointed  Deputy  Under 
Secretary  of  Defense  for  Research  and  Engineering  (Research  and  Advanced 
Technology).  Dr.  Martin  has  a  computer  science  background  and  will  be  over¬ 
seeing  the  management  of  the  VHSIC  and  Ada  programs. 


Mr.  Mark  Grove  is  the  new  Assistant  Deputy  Under  Secretary  (Research  and 
Advanced  Technology).  In  this  new  position  he  continues  to  be  responsible 
for  the  research,  development  and  acquisition  policies  for  computer  resources. 
Mr.  Grove  is  also  responsible  for  embedded  computer  or  mission  critical  com¬ 
puter  standardization  activities  currently  centered  on  controlling  and  reduc¬ 
ing  the  proliferation  of  high  order  languages  and  instruction  set  architec¬ 
tures. 
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Legislative  Changes  to  the  Computer  Acquisition  Process 

When  the  Erooks  Act,  Public  Law  89-306,  was  passed  in  October  1965, 
computer  technology  was  at  a  stage  of  development  where  hardware  considera¬ 
tions  were  the  major  concern  in  the  acquisition  process.  The  intent  of  this 
law  was  to  provide  for  the  economic  and  efficient  purchase,  lease,  mainte¬ 
nance,  operation  and  utilization  of  automatic  data  processing  equipment  by 
federal  departments  and  agencies.  As  technology  advanced,  hardware  cost 
declined,  while  software  cost  escalated,  and  this  has  required  that  in¬ 
creased  management  attention  be  devoted  to  the  software  acquisition  process. 
Within  the  Department  of  Defense,  the  acquisition  of  mission  critical  com¬ 
puter  resources  is  differentiated  from  general  purpose  computers  used  for 
routine  business  applications  and  is  therefore  managed  under  separate  poli¬ 
cies. 


The  distinction  between  general  purpose  ADP  equipment  and  DoD's  embedded 
computer  systems  was  recognized  in  Section  908  of  the  Department  of  Defense 
Authorization  Act  of  1982,  (The  Warner  Amendment)  Public  Law  97-86.  This 
law,  codified  as  Title  10  U.S.C.  Section  2315,  provides  the  DoD  with  an  in¬ 
centive  to  seek  improved  and  streamlined  methods  and  practices  for  the  acqui¬ 
sition  of  computer  resources  used  in  mission  critical  applications.  Under 
this  law,  we  have  coined  the  term  "Mission  Critical  Computer  Resources  (MCCR)" 
to  refer  to  any  automatic  data  processing  equipment  or  services  if  the  func¬ 
tion,  operation,  or  use  invo lve s  intelligence,  cryptologic  activities  related 
to  national  security,  command  and  control,  equipment  which  is  part  of  a 
weapon  system  or  which  is  critical  to  the  direct  fulfillment  of  military  or 
intelligence  missions. 

The  Establishment  of  a  Standardization  Area  for  Embedded  Computer  Resources 

Under  the  Defense  Standardization  Program,  a  new  standardization  area 
has  been  established  to  help  reduce  software  cost  and  improve  the  management 
of  Embedded  Computer  Resources  or,  now  more  accurately,  "Mission  Critical 
Computer  Resources"  within  DoD.  An  Embedded  Computer  Resources  standardiza¬ 
tion  program  plan  has  been  developed  that  identifies  ongoing  government  and 
industry  standards  activities  in  this  technology  area  as  well  as  related 
areas  where  standards  will  be  needed  in  the  future  as  the  technology  evolves. 
This  management  plan  outlines  objectives  and  establishes  priorities,  mile¬ 
stones  and  resource  allocations  consistent  with  the  identified  standardiza- 
documents  that  need  to  be  developed,  revised  or  cancelled.  The  standardiza¬ 
tion  initiatives  addressed  in  the  plan  are  concentrated  primarily  on  the 
standardization  of  software  high  order  languages,  architectures,  software 
documentation,  quality  control,  configuration  management  and  their  related  data 
item  descriptions.  These  standards  are  needed  to  encourage  competition  and 
reduce  the  downstream  logistics  and  maintenance  costs  during  the  out  years 
when  there  will  be  a  shortage  of  qualified  software  personnel.  Since  soft¬ 
ware  will  continue  to  be  labor  intensive,  we  need  to  do  everything  possible 
to  encourage  standardization  and  encourage  open  competition  in  these  cost 
driver  areas. 

DoD's  Common  Language  Effort 

A  first  step  in  reducing  the  number  of  programming  languages  for  weapon 
applications  was  to  adopt  an  interim  list  of  approved  languages.  This  list 
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is  being  revised  to  contain  8  specific  languages  which  shall  be  used  on  all 
major  defense  systems  unless  it  is  demonstrated  that  none  of  the  approved 
languages  are  technically  practical  or  cost  effective  over  the  system  life 
cycle.  The  second  step  towards  the  standardization  of  high  order  languages 
is  the  implementation  and  adoption  of  the  Ada*  programming  language  specified 
in  MIL-STD-1815 .  Ada  is  now  being  coordinated  as  both  a  national  and  inter¬ 
national  standard  through  the  ANSI  and  ISO  committees. 

Standardization  of  Computer  Architectures 

The  Department  of  Defense  has  been  convinced,  because  of  advances  in 
hardware  technology,  that  the  standardization  should  be  technology  transparent 
and  that  computer  standardization  requirements  should  be  expressed  through  a 
limited  number  of  instruction  set  architectures  (ISA's).  This  policy  has 
been  expressed  in  a  draft  DoD  Instruction  5000. 5X.  The  primary  objective  of 
Instruction  5000. 5X  is  curtailment  of  high  costs  resulting  from  hardware  and 
software  proliferation,  and  in  particular,  logistics  support,  personnel  and 
training  costs  in  the  field.  It  is  also  believed  that  the  effects  of  limit¬ 
ing  the  number  of  ISA's  will  result  in  improved  software  development;  it  has 
been  shown  to  yield  improved  competitiveness  of  hardware  procurements.  MIL- 
STD-1750  is  a  shining  example. 

While  there  is  general  agreement  that  standardization  has  merits,  there 
have  been  concerns  expressed  by  the  Congress  and  industry  regarding  the  DoD's 
approach  and  the  level  at  which  standards  should  be  applied  such  as  the  com¬ 
puter  interface  level.  The  standardization  of  ISA's  has  become  a  highly 
controversial  issue,  since  it  may  well  affect  competition  for  hardware  pro¬ 
curements. 

Opponents  of  the  DoD  strategy  claim  that  some  DoD  standards  programs  are 
so  limiting  that  that  may  decrease  competition  and  in  some  instances  act  as 
a  deterrent  to  innovation.  We  do  not  agree  with  these  claims.  Again,  MIL- 
STD-1750  has  demonstrated  that  truth  lies  to  the  contrary.  This  controversy 
resulted  in  a  special  Defense  Science  Board  Task  Force  Study  to  review  the 
Instruction  Set  Architecture  Standards  issue. 

Defense  Science  Board  on  Embedded  Computer  Acquisition  and  Management 

A  special  Defense  Science  Board  Task  Force  on  Embedded  Computer  Resour¬ 
ces  Acquisition  and  Management  was  chartered  in  August  1981  to  review  the 
ISA  and  other  embedded  computer  standardization  issues.  The  task  force  met 
between  September  1981  and  January  1982  to  advise  the  Secretary  of  Defense 
and  Under  Secretary  of  Defense  for  Research  and  Engineering  on  overall  re¬ 
search,  engineering,  acquisition  and  management  issues  and  to  provide  long- 
range  guidance  in  these  areas.  The  task  force  provided  an  evaluation  of 
the  current  and  proposed  policies  of  the  Department  relative  to  management, 
standardization,  current  and  planned  research  and  development  programs,  and 
recommended  improvements  which  appear  possible  and  practical.  They  also 
reviewed  the  effect  of  recent  changes  to  Public  Law  and  the  opportunities  for 
improvement  in  the  internal  management  process  which  these  changes  offer. 
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The  Defense  Science  Board  Task  Force  final  report  lists  several  major 
findings  and  specific  recommendations  to  the  Under  Secretary  of  the  Defense 
for  Research  and  Engineering.  Although  this  report  has  not  been  officially 
released  at  this  writing,  its  major  findings  were  that  continued  development 
and  application  of  computer  standards  are  needed  to  gain  and  maintain  control 
over  DoD's  accelerating  computer  acquisition,  logistics  and  maintenance  costs. 
They  recommended  that  the  DoD  adopt  a  limited  number  of  Instruction  Set  Arch¬ 
itecture  Standards  to  control  the  life  cycle  costs  associated  with  the  long 
life  of  major  systems.  The  Task  Force  recommended  the  policy  on  High  Order 
Languages  be  updated  to  add  Ada  to  the  approved  list  and  to  remove  the  out¬ 
dated  languages.  Finally,  it  was  recommended  that  the  policy  on  management 
of  computer  resources  be  revised  to  emphasize  the  "software  first"  approach 
to  system  design  and  development. 

General  Accounting  Office  Letter  Report  Entitled  "DoD  Instruction  5000. 5X 
Standard  Instruction  Set  Architecture  For  Embedded  Computers" 

At  the  request  of  Congressman  Jack  Brooks,  the  General  Accounting  Office 
conducted  an  investigation  of  the  Defense  Department's  plans  to  implement  DoD 
Instruction  5000. 5X.  The  GAO  report  (MASAD-82-16)  dated  January  27,  1982 
stated  that  if  this  policy  were  implemented  within  the  Department,  it  would 
(1)  inhibit  DoD's  use  of  technical  innovations  by  private  companies,  (2)  lock 
DoD  into  obsolete  technology,  and  (3)  severely  restrict  competition  to  those 
companies  willing  to  implement  obsolete  technology  within  DoD.  The  report 
recommended  that  the  Secretary  of  Defense  not  implement  DoD  Instruction 
5000. 5X.  Our  official  response  rebutted  the  GAO  assertions  in  some  detail. 

In  general,  the  Secretary  disagreed  with  GAO's  findings  and  recommendations. 

An  Assessment  of  DoD's  Software  Standardization  Initiatives 

The  major  objectives  of  standardization  within  the  DoD  are  to  improve 
operational  readiness,  enhance  interchangeability,  reliability  and  maintain¬ 
ability  of  military  equipments  and  reduce  acquisition,  logistics  and  life 
cycle  costs.  Through  the  standardization  of  high  order  languages,  instruc¬ 
tion  set  architectures  and  improved  computer  software  documentation,  DoD's 
software  costs  should  remain  under  manageable  control.  Although  it  is 
recognized  that  DoD's  software  costs  will  continue  to  increase  in  the  near 
term,  it  is  anticipated  that  through  our  standardization  efforts  this  rate 
of  increase  will  be  controlled  and  even  reduced. 

Standardization  based  on  a  selected  instruction  set  architecture  is  a 
concept  used  by  computer  manufacturers  to  develop  families  of  compatible 
computers.  In  an  article  by  Bhandarkar  in  IEEE  Computer  Magazine  it  states: 

"The  goals  of  architecture  management  .  .  .  are  twofold;  to  ensure 
the  consistent  implementation  of  .  .  .  architecture  and  to  provide  a 
rational  process  for  the  evolution  of  that  architecture.  The  em¬ 
phasis  is  clearly  on  maintaining  architectural  stability  by  elimina¬ 
ting  gratuitous  differences.  At  the  same  time  .  .  .  future  enhance¬ 
ments  will  be  incorporated  into  the  architectures  in  a  carefully 
controlled  manner."  [l] 

[l]  IEEE  Computer  Magazine,  February  1982  "Architecture  Management  for 
insuring  Software  Compatibility  in  the  VAX  Family  of  Computers," 

Dileep  Bhandarkar. 
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If  this  is  what  industry  does,  then  why  is  it  bad  for  the  DoD? 

The  standardization  of  instruction  set  architectures  continues  to  be  a 
politically  sensitive  issue.  DoD's  position  is  that  it  continues  to  support 
a  limited  number  of  instruction  set  architectures  such  as  MIL-STD-1750,  to 
help  reduce  and  control  the  software  costs. 


EMBEDDED  COMPUTERS  HARDWARE  vs  SOFTWARE 
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COMPARISON  BETWEEN  GENERAL  PURPOSE 
AUTOMATIC  DATA  PROCESSING  EQUIPMENT  AND 
COMPUTERS  USED  IN  DEFENSE  CRITICAL  SYSTEMS 
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ADPE  -  AUTOMATIC  DATA  PROCESSING  EQUIPMENT 

ECR  -  EMBEDDED  COMPUTER  RESOURCES 

MCCR  -  MISSION-CRITICAL  COMPUTER  RESOURCES 
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•  Is  management  and  oversight  adequate? 

•  What  is  the  effect  of  legislative 
environment? 


MAJOR  ISSUES 
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Can't  utilize  Ada  efficiently.  .  . 

—  Not  true,  but  HLL  machines  may  come 
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detailed  studies, 

•  Army  increase  Ada  portion  of  MCF  Program 

•  Navy  increase  funding  of  Ada  effort 
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•  Add  or  delete  based  upon  experience  and  analysis 


COMPTROLLER  GENERAL  OP  THE  UNITED  STATES 
WASHINGTON  O.C  *MM 


B-199008 

JANUARY  27. 1982 

The  Honorable  Jack  Brooks 
Chairman,  Committee  on  Government 
Operations 

House  of  Representatives 
Dear  Hr.  Chairman: 

Subject:  000  Instruction  5000. SX,  Standard  Instruction  Set 
Architectures  For  Embedded  Computers  (MASAD-82-16) 

On  July  30,  1981,  you  requested  that  we  review  the  Department 
of  Defense  (DOD)  plans  to  implement  proposed  000  Instruction 
5000. 5X.  Your  request  raised  a  number  of  questions  about  the  po¬ 
tential  impact  of  implementing  the  proposed  instruction,  we  have 
responded  to  your  five  specific  questions  in  enclosure  I. 

As  we  understand  it,  the  primary  objective  of  Instruction 
5000. 5X  is  curtailment  of  high  costs  resulting  from  hardware 
and  software  proliferation,  and  in  particular,  logistics  support 
costs  in  the  field.  TO  accomplish  this,  DOD  has  chosen  to  limit 
the  number  of  architectures  that  could  be  used  for  the  design 
and  development  of  computer  hardware  and  software  for  the  tactical 
environment.  Moreover,  OOD  would  require  ownership  of  standard 
architectures  for  military-embedded  computers.  Although  this 
proposed  instruction  has  merit  when  considered  in  context  of 
the  hardware/software  environment  that  existed  during  the  mid- 
1970s,  our  evaluation  raises  some  serious  issues  that  challenge 
|  its  validity  in  the  time  frame  of  the  1980s.  Some  of  the  more 

salient  points  for  consideration  are: 

— Dramatic  advances  have  been  made  in  software  technology. 

DOD  has  recognized  that  a  lack  of  a  standard  programming 
language  is  a  major  contributor  to  the  high  cost  of  devel¬ 
oping  and  maintaining  software  for  military  applications. 

DOD  is  to  be  commended  for  its  initiative  to  fill  that  void 
by  developing  a  common  high-order  programming  language 
called  Ada.  Ada  very  specifically  aims  to  readily  adapt  a 
very  wide  variety  of  OOD  applications  to  most  present  (and 
future)  computer  architectures.  Ada  can  potentially  encom¬ 
pass  the  particularly  useful  aspects  of  future  architectural 
advances  and  make  .their  gains  available  to  users,  without 
their  having  to  learn  and  worry  about  how  the  gains  were 
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realized.  In  other  words,  aggressive  pursuit  of  a  standard 
high-order  language,  such  as  Ada,  could  alleviate  the 
software  proliferation  problem  and  at  the  same  time  permit 
the  Government  to  fully  capitalize  on  architectural  ad¬ 
vances. 

— Likewise  there  have  been  many  advances  in  computer  tech¬ 
nology.  These  advances  are  the  result  of  demands  made  by 
the  civilian  sector  for  more  reliable  and  rugged  computers. 
And  indeed,  the  civilian  sector  is  starting  to  impose  much 
stiffer  reliability  requirements  on  integrated  circuits. 

These  advances  will  be  realized  probably  at  little  or  no  cost 
penalty  because  all  integrated  circuits  will  be  made  to  the 
same  high  standards.  There  are  computer  companies  already 
marketing  highly  reliable  computers  through  the  use  of 
innovative  architectures.  These  modern  computers  have 
substantially  fewer  parts  and  in  many  cases  are  a  computer 
on  a  single  board  thereby  reducing  the  need  for  extensive 
logistics  support. 

--Improved  competition  using  militarized  versions  of  commer¬ 
cial  computers  will  open  up  competition  to  many  firms  that 
would  not  bid  on  specifications  with  DOD-owned  architectures. 
The  resulting  unit  prices  will  be  less  because  DOD  will 
not  pay  for  duplicating  hardware  development  and  control 
and  utility  software  development  as  it  proposed  to  do 
under  Instruction  5000. 5X.  Lower  hardware  unit  costs 
and  high  hardware  quality  are  in  fact  available  in 
the  commercial  market  because  of  the  technology  and 
broader  market  base. 

— DOD  ownership  of  architectures  would  seriously  inhibit 

competition  by  a  significant  portion  of  the  computer  indus¬ 
try,  and  therefore  DOD  would  not  have  the  flexibility  to 
capitalize  on  advances  in  computer  architectural  technol¬ 
ogy  in  a  timely  fashion.  The  ultimate  impact  would  result 
in  DOD  very  likely  running  the  risk  of  getting  locked  into 
obsolete  architectures. 

— DOD  would  not  be  able  to  efficiently  utilize  the  new  DOD 
programming  language  Ada  and  will  not  be  able  to  fully 
capitalize  on  the  anticipated  software  cost  savings  Ada 
was  designed  to  yield. 

— The  three  services  have  initiated  efforts  commensurate  with 
Instruction  5000. 5X;  for  example,  the  Army's  Military  Com¬ 
puter  Family,  the  Navy's  AN/UYK-43  and  44,  and  the  Air 
Force's  1750  programs.  In  a  previous  report  entitled  "The 
Department  of  Defense's  Standardization  Program  for  Military 
Computers— a  More  Unified  Effort  Is  Needed"  (LCD-80-69, 

June  18,  1980),  we  were  critical  of  both  the  Army  and  Navy 
efforts.  We  made  the  following  statements  in  that  earlier 
report  and  believe  they  are  even  more  valid  today: 
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"*  *  *  some  computer  manufacturers  are  already  design¬ 
ing  computers  with  modern  architectures  that  will  have 
Ada  compilers  available.  These  or  other  manufacturers 
will  probably  offer  follow-on  computers  that  will 
directly  carry  out  Ada  instructions  and  substantially 
improve  performance  reliability.  Because  these  changes 
provide  better  support  options,  such  as  building  more 
redundancy  into  systems,  they  should  compel  the  De¬ 
partment  to  further  evaluate  the  level  of  standardiza¬ 
tion  to  be  achieved  before  allowing  the  Army  and  Navy 
to  commit  themselves  *  *  ♦  for  the  long  term.  (Em¬ 
phasis  added.) 

"We  view  the  need  for  architecture  standardization  as  a 
function,  in  part,  oi  the  availability  of  Ada  as  tHe 
standard  computer  programming  language.  Because  Ada 
is  being  developed  to  be  a  machine-transportable 
language  with  a  relatively  low  life  cycle  maintenance 
cost,the  need  for  standard  architectures  may  be  di¬ 
minished  when  it  is  available  *  *  *.*  (Emphasis  added . ) 


CONCLUSIONS 

We  believe  that  DOD  can  accomplish  its  objectives  more 
effectively  through  exploitation  of  advances  made  with  high-order 
language  standardization  and  related  hardware  technology.  Further, 
we  believe  implementation  of  Instruction  5000. 5X  would  preclude 
DOO's  ability  to  make  use  of  current  and  anticipated  advances  in 
software  and  related  hardware  technology. 

RECOMMENDATIONS 

We  recommend  that  the  Secretary  of  Defense  not  implement 
Instruction  5000. 5X. 

We  also  recommend  that  the  Secretary  of  Defense  direct  the 
services  to  reevaluate  their  ongoing  efforts  and  demonstrate  why 
they  are  more  cost  effective  than  standardizing  on  a  high-order 
language  such  as  Ada  and  relying  on  the  computer  industry  to  provide 
the  stimulus  for  computer  architectural  innovations. 

SCOPE  AND  METHODOLOGY 

During  our  review,  we  contacted  officials  representing  16  com¬ 
puter  manufacturers,  3  system  contractors  who  incorporate  embedded 
computers  in  the  systems  they  develop,  and  4  industry  associations 
representing  manufacturers  of  computers  and  electronic  equipment. 

We  reviewed  position  statements  and  correspondence  regarding 
Instruction  5000. 5X.  We  also  contacted  program  officials  and 
reviewed  program  documentation  regarding  Ada,  the  Army's  Military 
Computer  Family,  the  Air  Force's  1750,  and  the  Navy's  AN/UYK-43 
and  44  efforts. 
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Our  review  was  performed  in  accordance  with  our  standards 
for  audits  of  governmental  organizations,  programs,  activities, 
and  functions. 

As  arranged  with  your  office,  we  did  not  obtain  official 
agency  comments  on  this  report  and  we  plan  no  further  distribu¬ 
tion  of  this  report  until  30  days  from  the  date  of  the  report, 
unless  you  publicly  announce  its  contents  earlier.  Then,  we 
will  send  copies  to  interested  parties  and  make  copies  available 
to  others  upon  request. 


Sincerely  yours. 


Enclosure 


Acting  Comptroller  General 
of  the  United  States 


ENCLOSURE  I 


ENCLOSURE  I 


RESPONSES  TO  SPECIFIC  QUESTIONS 

REGARDING  INSTRUCTION  5000. 5X 

WHAT  EFFECT  WOULD  INSTRUCTION  5000. 5X 
HAVE  ON  THE  USE  OF  COMPETITION  IN  THE 
DEPARTMENT  OF  DEFENSE? 

Instruction  5000. 5X  would  effectively  preclude  any  commercial 
architecture  from  the  Department  of  Defense  ( DOD) -approved  list 
because  DOD  must  have  full  and  clear  data  rights  to  all  architec¬ 
tures  listed.  Currently,  only  DOD  developed  and  funded  architec¬ 
tures  have  been  approved.  The  Army's  unsuccessful  attempt  to  use 
a  commercial  architecture  in  its  Military  Computer  Family  program 
is  an  example  of  how  this  policy  will  inhibit  commercial  architec¬ 
tures  from  competing  for  embedded  computer  systems. 

The  Army's  unsuccessful  attempt  was  caused  by  (1)  the  reluc¬ 
tance  of  the  commercial  firm  to  accept  Army  assurance  that  its 
proprietary  architecture  would  not  be  remarketed  commercially 
and  (2)  the  lack  of  industry  interest  in  providing  hardware  based 
on  a  competitor's  design.  It  is  fortunate  that  this  attempt  was 
unsuccessful  because  the  commercial  firm  involved  is  now  marketing 
a  new  architecture  due  to  the  prior  one's  limitations. 

A  majority  of  the  industry  officials  interviewed  assured  us 
that  they  would  not  compete  on  DOD-embedded  computer  procurements 
if  they  had  to  use  DOD-approved  architectures.  These  officials 
were  concerned  that  their  key  personnel  would  be  diverted  from 
current  work  to  meet  the  production  needs  of  the  DOD-embedded 
computers,  which  have  obsolete  architectures.  Therefore,  the  key 
personnel  would  lose  their  current  technological  expertise.  A 
smaller  number  of  industry  officials  felt  that  Instruction  5000. 5X 
would  encourage  competition  in  DOD  procurements.  However,  these 
officials  generally  represented  companies  currently  under  DOD 
contracts  implementing  approved  architectures. 

WHAT  EFFECT  WOULD  INSTRUCTION  5000. 5X 
HAVE  ON  THE  CURRENT  COMPUTER  INDUSTRY? 

Most  industry  officials  and  some  military  officials  stated 
that  Instruction  5000. 5X  would  effectively  eliminate  many  compe 
tent  computer  companies  from  the  militarized  embedded  computer 
market.  Very  few  companies  are  willing  to  compete  on  procurements 
mandating  obsolete  architectures.  Under  the  current  Navy  program 
for  the  development  of  the  AN/UYK-43  and  44  computers  only  two 
companies  responded. 

WOULD  INSTRUCTION  5000. 5X  LOCK 
DOD  INTO  OBSOLETE  TECHNOLOGY? 

Instruction  5000. 5X  will  minimize  DOD's  opportunities  to 
capitalize  on  new  architecture  developments  in  the  commercial 
marketplace.  Computer  architecture  is  a  rapidly  evolving 
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technology  and  has  a  profound  effect  on  the  application  of  computer 
technology.  As  the  computer  industry  improves  the  application 
of  high-order  languages,  such  as  Ada,  it  also  needs  improvements 
and  innovations  in  computer  architectures  to  better  support  the 
use  of  high-order  languages. 

Most  of  the  industry  officials  stated  that  DOD  would  defi¬ 
nitely  have  obsolete  equipment  due  primarily  to  the  fact  that 
the  approved  architectures  in  Instruction  5000. 5X  are  or  will 
be  obsolete  by  the  time  they  are  implemented.  We  were  also  told 
that  these  architectures  do  not  lend  themselves  to  efficiently 
utilize  the  new  DOD  programming  language  Ada  and  will  not  be  able 
to  fully  capitalize  on  the  anticipated  software  cost  savings  Ada 
was  designed  to  yield. 

The  architectures  listed  in  Instruction  5000. 5X  do  not  include 
many  modern  concepts  such  as  stack-oriented  architectures,  memory- 
to-memory  architectures,  efficient  multiprocessing  support,  multi¬ 
ple  concurrent  tasking  support,  pipelined  architectures,  signal 
processing  architectures,  image  processing,  and  array  computers. 
Therefore,  technological  advances  in  computer  architectures  will 
be  ruled  out  because  of  Instruction  5000. 5X. 

ARE  COMMERCIAL  OFF-THE-SHELF  COMPUTERS 
CURRENTLY  AVAILABLE  THAT  COULD  SATISFY 
POD'S  MAJOR  NEEDS  FOR  EMBEDDED  COMPUTERS? 

Militarized  versions  of  off-the-shelf  commercial  computers 
are  available,  work  very  effectively  with  modern  software,  and 
can  offer  current  computer  technology  at  reasonable  costs.  Com¬ 
mercial  computers  have  the  advantage  of  giving  program  managers 
the  latest  technology  and  the  most  effective  and  efficient  archi¬ 
tecture  for  the  particular  job.  Commercial  computers  also  (1) 
have  lower  life-cycle  costs,  (2)  can  be  militarized  to  the  point 
where  they  are  rugged  enough  for  combat,  (3)  can  help  ease  the 
logistics  support  burden,  and  {4)  provide  more  competition. 

Today,  nearly  all  of  the  research  and  development  in  electron¬ 
ics  is  funded  by  the  commercial  sector  (particularly  in  computer 
technology)  and  is  available  to  DOD  through  the  purchase  of  mili¬ 
tarized  commercial  products.  Military  use  of  commercial  technology 
would  significantly  reduce  applications  development  and  software 
life-cycle  costs.  For  example,  if  DOD  utilized  commercial  archi¬ 
tectures,  most  of  the  associated  research  and  development  costs 
of  the  architecture  and  systems  software  would  be  borne  by  the 
manufacturer  and  not  DOD.  Although  DOD  is  spending  hundreds  of 
millions  of  dollars  for  customized  architectures,  it  has  not 
offered  adequate  justifications  for  its  dominant  reliance  on 
noncommercial  architectures. 

The  market  for  embedded  computers  represents  about  5  percent 
of  the  total  computer  market.  This  means  that  all  embedded  com¬ 
puter  activities  must  compete  for  technical  resources  with  a  market 
that  is  about  20  times  larger.  We  believe  that  DOD  would  do  better 
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by  utilizing  the  resources  of  the  entire  market  by  opening  the 
procurements  to  all  the  computer  industry.  Industry  could  then 
offer  its  best  architectures,  technology,  and  software  support  on 
a  system- by- system  basis. 

Militarized  versions  of  commercial  computers  already  exist. 

For  example,  militarized  versions  of  Data  General  Corporation  and 
Digital  Equipment  Corporation  computers  are  used  in  a  variety  of 
weapons,  communications,  and  electronic  warfare  projects  within  all 
three  services.  Ruggedized  IBM  minicomputers  are  used  extensively 
in  the  Marine  Corps'  Source  Data  Automation  Program.  Ruggedized, 
shock  mounted,  and  straight  commercial  versions  of  other  vendors' 
hardware  are  widely  used  in  command  and  control  and  intelligence 
applications  through  the  AN/GYQ-2K V)  program. 

Commercial  hardware  itself  is  becoming  more  and  more  rugged 
because  ruggedness  is  being  required  in  laboratory,  manufacturing, 
control,  vehicle,  airborne,  and  shipboard  environments.  More  dense 
circuitry  and  improved  packaging  have  contributed  to  this  trend. 

As  a  result,  today's  computers  operate  successfully  under  more 
adverse  conditions  than  yesterday's  and  will  perform  even  better 
in  the  future. 

It  is  also  argued  that  commercial  technology  will  help  solve 
DOD's  problem  of  logistical  support  and  wartime  survivability. 
Because  computers  are  using  less  circuit  cards  than  before,  the 
problem  of  maintenance  or  logistic  support  is  diminishing.  Past 
computers,  in  the  1970s,  had  up  to  200  circuit  cards  compared  to 
today's  equivalent  that  uses  only  13  circuit  cards  and  is  smaller 
and  faster.  Today's  AN/UYK-19  (a  military  version  of  a  commercial 
computer)  uses  only  13  circuit  cards  and  the  new  "B"  model  only 
7  circuit  cards. 

Adherents  of  commercial  technology  argue  that  it  is  less 
expensive  and  more  practical  to  stock  entire  computer  spares  in 
the  field  (as  the  field  replaceable  unit)  than  to  have  more 
maintenance  people  in  the  field  to  diagnose  and  swap  out  an 
individual  problem.  Their  logistics  remedy  is  to  place  whole 
units  in  the  field  and  ship  them  back  to  a  central  depot  for 
repair.  This  reduces  costs  because  an  individual  technician  can 
service  a  greater  number  of  machines.  Also,  as  computers  become 
smaller,  it  will  be  more  cost  effective  to  stock  entire  computer 
spares  in  the  field. 

It  is  easier  to  diagnose  hardware  problems  due  to  advances 
in  commerical  technology.  New  hardware  design  allows  relatively 
unskilled  personnel  to  isolate  problems.  Field  maintenance  will 
consist  of  replacing  the- field  unit.  This  will  be  facilitated  by 
self-testing  logic  in  the  unit  and  fault-isolating  diagnostics. 

Throwaway  computers  are  becoming  possible  because  many 
field  units  will  be  a  single  circuit  board,  not  several  cabinets 
of  electronics.  Commercial  industry  is  already  at  the  point  where 
several  boards  are  throwaway  units.  With  the  high  cost  associated 
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with  maintaining  equipment  in  the  £ield,  DOD  could  probably  justify 
throwing  away  an  even  higher  percentage  of  circuit  boards.  Units 
that  can  and  should  be  repaired  will  be  shipped  back  to  a  central 
depot  where  commercial  vendors  will  repair  the  failed  component. 
This  will  free  critical  military  personnel  from  learning  skills 
that  are  more  readily  available  from  private  industry.  While 
this  service  could  be  provided  by  the  hardware  manufacturer,  it 
is  also  possible  to  compete  this  separately. 

Survivability  and  the  ability  to  maintain  continuity  of 
operations  will  be  enhanced  not  only  by  simplified  logistics  but 
also  by  distributive  processing.  In  the  future,  as  computers  be¬ 
come  smaller  and  smaller,  we  will  see  individual  computers  designed 
to  implement  individual  functions  or  to  support  an  individual  com¬ 
mander  or  operator  in  the  field.  These  individual  computers  will 
then  be  connected  together  in  a  network,  both  locally  within  a 
building  and  more  remotely  over  wider  areas.  When  one  of  these 
computers  is  down,  for  whatever  reason,  it  can  be  quickly  discon¬ 
nected  from  the  network  and  a  spare  unit  plugged  into  its  place. 

Lastly,  opponents  of  standard  architectures  argue  that  using 
commercial  hardware  will  increase  competition.  Instead  of  using 
standard  architectures  for  all  programs,  there  would  be  competi¬ 
tive  selection  of  a  computer  system  for  each  major  new  program. 

The  competition  would  be  based  on  technology  as  well  as  price. 

The  pressure  to  win  new  programs  would  encourage  the  suppliers  to 
introduce  new  technology  without  added  cost  to  DOD. 

SHOULD  STANDARDIZATION  OCCUR  AT  THE 
INSTRUCTION  SET  ARCHITECTURE  LEVEL  OR  AT 
THE  HIGHER  LEVEL  LANGUAGES,  SUCH  AS  ADA? 

Cost  effective  standardization  for  DOD-embedded  computers 
requires  standardization  at  the  high-order  language  level,  such 
as  Ada.  The  proliferation  of  languages  contributes  significantly 
to  the  high  cost  and  poor  quality  of  software  used  in  military 
computer  applications.  According  to  the  DOD  High-Order  Language 
Working  Group,  none  of  the  many  programming  languages  used  in 
the  military  is  suitable  as  a  standard  language  for  military 
applications— including  the  Navy's  CMS-2,  the  Air  Force's  JOVIAL, 
and  the  Army's  TACPOL  which  have  been  established  as  interim 
standard  languages.  Four  of  the  five  architectures  currently 
listed  under  Instruction  5000. 5X  are  oriented  to  using  these  lan¬ 
guages. 

Studies  made  by  the  Defense  Advanced  Research  Projects  Agency 
and  by  Decisions  and  Designs,  Inc.,  predicted  that  as  the  standard 
DOD  language,  Ada  will  result  in  substantial  cost  savings  DOD-wide 
through  common  software,  improved  programmer  productivity,  and  new 
technical  features.  According  to  these  studies,  DOD  could  save 
as  much  as  $24  billion  from  1983  to  1999. 

Because  DOD  is  implementing  Ada  as  its  standard  programming 
language  for  military  applications,  computer  manufacturers  are 
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currently  developing  Ada-oriented  computers  and  Ada  compilers 
using  the  latest  technology  with  substantially  improved  perform¬ 
ance  and  reliability.  As  a  result,  the  need  for  standard  comput¬ 
ers  and  instruction  set  architectures  has  diminished. 

The  consensus  of  opinion  from  most  of  those  we  interviewed 
during  this  review  was  that  DOD  should  standardize  at  a  high- 
order  language,  such  as  Ada,  and  let  the  computer  industry  innovate 
at  the  architectural  and  hardware  levels. 


THE  SECRETARY  OF  DEFENSE 
WASHINGTON.  O.C.  2030* 


2  APR  1982 


Honorable  Jack  Brooks 
Chairman 

Committee  on  Government  Operations  '  • ' 

House  of  Representatives 
Washington,  D.  C.  20515 
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Dear  Mr.  Chairman 

This  is  in  reply  to  your  recent  letter  which  provided  a  copy  of 
GAO  letter  report,  "DoD  Instruction  5000. SX,  Standardization 
Set  Architectures  for  Embedded  Computers,'1  (MASAD-82-16) ,  dated 
January  27,  1982,  (OSD  Case  #5889). 

I  must  respectfully  disagree  with  your  conclusions  that: 

•  ’’...this  (proposed)  policy  would  lock  DoD  into  the  use 
of  inferior  technology.” 

•  "...DoD  would  not  be  able  to  take  advantage  of  private 
industry’s  technical  innovations." 

•  "...it  would  severely  restrict  competition  to  those 
companies  willing  to  help  DoD  implement  obsolete 
technology." 

Our  experience  to  date  has  demonstrated  the  opposite  effect. 
Hence,  we  believe  the  proposed  policy  is  an  established  success, 
even  before  formal  issuance. 

The  GAO  was  invited  to  observe  meetings  of  the  recent  Defense 
Science  Board  review  of  this  subject.  However,  the  two  groups 
reached  quite  different  conclusions.  Further,  the  conclusions 
and  recommendations  of  the  GAO  report  do  not  track  with  their 
earlier  reviews  of  this  same  issue  ("The  Department  of  Defense’s 
Standardization  Program  for  Military  Computers- -A  More  Unified 
Effort  is  Needed,"  June  18,  1980,  LCD-80-69). 

One  recommendation  from  that  earlier  report,  and  echoed  in  the 
current  letter  report,  is  that  Ada  should  be  implemented  as  DoD’s 
standard  programming  language.  We  agree.  We  followed  GAO’s 
recommendation  to  establish  a  tri-Service  program  office  for  that 
purpose. 
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;  Experience  with  the  principles  of  5000. SXs  although  it  has  not 
•V  ..  been  formally  issued,  are: 

|  -  There  were  12  significant  bidders  for  the  Army  Military 

Computer  Family  (MCF)  Program  based  upon  the  Government 
MIL-STD-1862  Instruction  Set  Architecture  (ISA).  Earlier, 
when  the  program  was  based  upon  a  commercial  ISA,  there 
were  only  two. 

[  -  There  are  ever  20  suppliers  of  computers  built  to  MIL-STD- 

1750  including  four  from  England  (Enclosure  1). 

Significant  cost  avoidances  have  bsen  demonstrated  on  the 
F-lll  upgrade  and  the  F-5GII  aircraft  as  a  direct  result 
I  of  this  available  competition. 

The  Army  is  using  MIL- STD- 1750  equipment  in  at  least  two 
systems . 

-  There  is  a  formal  agreement  for  the*  Air  Force  to  use  the 
Army's  MIL-STD-1862  ISA  when  available. 

As  we  read  the  current  report,  there  are  two  salient  differences 
in  viewpoint  between  our  position,  which  has  evolved  over  the  past 
six  years,  and  that  of  the  GAO  and  a  small  segment  of  the  computer 
industry: 

^  •  Defense  must  be  concerned  with  the  acquisition  of  adequate 

equipment  (minimum- essential  with  provision  for  realistic 
growth)  and  the  life-cycle  support  of  that  equipment. 
Post-acquisition  costs  normally  run  from  three  to  ten  times 
"  original  acquisition  costs  for  hardware.  Software  costs 
for  a  system  over  its  life  also  range  to  several  times 
the  hardware  costs  and  the  proportion  dedicated  to  soft¬ 
ware  is  growing. 

•  We  do  not  agree  with  the  GAO  assessment  of  "commercial" 
versus  "military"  technology  in  this  field. 

More  specific  discussion  of  the  report  and  responses  to  the 
specific  questions  voiced  in  its  Enclosure  I  are  given  in 
Enclosures  2  and  3,  respectively. 

The  Defense  Science  Board  Task  Force  on  Embedded  Computer  Resources 
Acquisition  and  Management  has  reported  out  to  the  full  Defense 
Science  Board.  Their  findings  and  recommendations  with  respect 
to  proposed  Instruction  5000. 5X  are  summarized  in  Enclosure  4. 

The  Board,  in  accepting  the  Task  Force  results,  recommends  that 
we  proceed  with  5000. 5X  and  further  recommends  that  we  work  with 
industry  to  seek  a  means  to  add  "commercial"  Instruction  Set 
Architecture  to  its  list.  We  will  aggressively  pursue  that  added 
recommendation. 
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The  Task  Force's  final  report  is  in  preparation  and  should  be 
available  by  mid-A:3ril.  I  will  have  a  copy  provided  to  you  as 
soon  as  possible.  In  the  interim,  if  you  so  desire,  I  would  be 
pleased  to  arrange  a  briefing  on  this  topic  by  the  Task  Force  or 
by  my  staff. 

GAO's  second  recommendation  to  limit  our  standardization  efforts 
to  programming  language  alone  is  not  practical  at  this  time.  We 
do  not  agree  that  significant  architectural  innovations  are  nearby. 
We  do  not  believe  chat  a  technological  filibuster  while  awaiting 
breakthrough  and  production  availability  . s  sound.  We  will  follow 
closely  the  results  of  industry-sponsored  research  as  well  as  that 
sponsored  by  DoD  and  make  every  honest  effort  to  select  the  most 
appropriate  equipment  for  our  needs. 

We  have  explicitly  designated  the  Under  Secretary  of  Defense, 
Research  and  Engineering,  as  the  Senior  Official  to  be  responsible 
for  all  computer  acquisitions  covered  by  10  U.S.C.  2315.  We 
issued  interim  guidelines  for  these  acquisitions  and  will  revise 
those  guidelines  by  July  31,  1982,  in  consultation  with  your 
Committee  and  Staff  and  with  the  Office  of  Management  and  Budget. 

Thank  you,  Mr.  Chairman,  for  your  continued  interest.  I  trust  that 
we  may  work  closely  together  to  resolve  any  remaining  concerns. 

Sincerely, 


Enclosures 

a/s 


COMPANIES  CURRENTLY  MARKETING  MXL-STD-1750A  PROCESSORS 


Bendix 

Collins  Division,  Rockwell 
Control  Data  Corporation 
Delco  Electronics 
Ferranti ,  Ltd.  (U.K.) 

Hughes  Aircraft  Co. 

IBM 

Litton  Industries 
Marconi  (U.K. ) 

Martin-Marietta  Corp. 
McDonnell-Douglas  Electronics 
Norden  Division,  Unit id  Technologies 
Plessey  (U.K.) 

Singer- Kearfott 
Sperry  UNIVAC 
Teledyne  Systems 
Wes ting house  Electric 


Mikros/McDonnell-Douglas 
Tracor/General  Electric 

VLSI  MICROPROCESSORS 

Fairchild /Honeywell 
National  Semiconductor 
Smith  Industries  (U.K.) 

VBSIC  PROIESSORS 

Texas  Instruments,  Inc. 
Westinghouse  Electric 


Enclosure  1 


Discussion  of  GAO  Letter  Report 
MDoD  Instruction  5000. 5X,  Standard  Instruction  Set 
Architectures  for  Embedded  Computers,"  (MASAD-82-16) 


"--Dramatic  advances  have  been  made  in  software  technology. 

DoD  has  recognized  that  a  lack  of  a  standard  programming  language 
is  a  major  contributor  to  the  high  cost  of  developing  and  maintain¬ 
ing  software  for  military  applications.  DoD  is  to  be  commended  for 
its  initiative  to  fill  that  void  by  developing  a  common  high  order 
programming  language  called  Ada.  Ada  very  specifically  aims  to 
readily  adapt  a  very  wide  variety  of  DoD  applications  to  most  present 
(and  future)  computer  architectures.  Ada  can  potentially  encompass 
the  particularly  useful  aspects  of  future  architectural  advances  and 
make  their  gains  available  to  users,  without  their  having  to  learn 
and  worry  about  how  the  gains  were  realized.  In  other  words, 
aggressive  pursuit  of  a  standard  high  order  language,  such  as  Ada, 
could  alleviate  the  software  proliferation  problem  and  at  the  san*i 
time  permit  the  Government  to  fully  capitalize  on  architectural 
advances . " 

Response:  Ada  is  indeed  coming  and,  when  implemented,  will  have  major 
impact  on  the  software  process.  There  have  not  been  dramatic  advances 
in  software  technology  and  the  inefficiencies  of  continuing  the  pro¬ 
liferation  of  the  past  will  live  on  for  decades  in  specific  systems. 
What  improvements  have  been  made  in  commercial  and  military  software 
development  and  support  processes  have  been  both  slow  and  inconsistent . 


"--Likewise  there  have  been  many  advances  in  computer  technology. 

These  advances  are  the  result  of  demands  made  by  the  civilian  sector 
for  more  reliable  and  rugged  computers.  And  indeed,  the  civilian 
sector  is  starting  to  impose  much  stiffer  reliability  requirements 
on  integrated  circuits.  These  advances  will  be  realized  probably  at 
little  or  no  cost  penalty  because  all  integrated  circuits  will  be  made 
to  the  same  high  standards.  There  aTe  computer  companies  already 
marketing  highly  reliable  computers  through  the  use  of  innovative 
architectures.  These  modern  computers  have  substantially  fewer  parts 
and  in  many  cases  are  a  computer  on  a  single  board  thereby  reducing 
the  need  for  extensive  logistics  support." 

Response:  By  standardizing  at  the  interface  between  software  and  the 
hardware  upon  which  it  runs,  DoD  can  gain  access  to  the  best  commercial 
processes  without  being  locked  to  single  suppliers.  Although  the 
commercial  market  does  demand  better  reliability,  their  needs  do  not 
match  those  of  the  military  environment.  The  "innovative"  architectures 
used  in  the  commercial  world-  are  at  a  system  level  and  have  little  or 
nothing  to  do  with  ISAs.  The  computer-on-a-board  is,  in  fact,  am 
argument  favoring  ISA  standardization  because  any  computer  instantia¬ 
tion  must  have  a  native  ISA  and  for  the  logistics  argument  to  hold, 
standard  hardware  is  implied  and  hence  a  standard  ISA  is  demanded, 
de  facto.  Working  from  hardware  up  implies  restricted  competition, 
by  any  practical  measure;  starting  with  the  ISA  first  allows  open  and 
equitable  competition  so  as  long  as  the  actual  selection  does  not 
itself  force  restriction;  i.e.,  so  long  as  the  Government  has  unlimited 
rights  in  that  ISA. 
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"--Improved  competition  using  militarized  versions  of  commercial 
computers  will  open  up  competition  to  many  firms  that  would  not 
bid  on  specifications  with  DoD-owned  architectures.  The  resulting 
unit  prices  will  oe  less  because  DoD  will  not  pay  for  duplicating 
hardware  development  and  control  and  utility  software  developmert 
as  it  proposed  to  do  under  Instruction  5000. SX.  Lower  hardware 
unit  costs  and  hi^h  hardware  quality  are  nn  fact  available  in  the 
commercial  market  because  of  the  technology  and  broader  market 
base. " 

Response:  It  has  been  demonstrated  that  basing  competition  on  a 
commercial  computer  restricts  competition.  Far  more  companies 
have  bid  on  MIL-STD-1750  and  MIL-STD-1862  based  procurements  thai 
have  ever  been  experienced  with  other  approaches.  "Commercial 
computers"  is  at  best  a  shibboleth  for  restricted  competition. 
Attachment  1  comp  ires  performance  and  cost  of  a  representative 
"equivalent"  commercial  product  to  the  Navy  AN/UYK-43  and  44.  The 
facts  are  contrary  to  the  assertion. 


"--DoD  ownership  of  architectures  would  seriously  inhibit  competition 
by  a  significant  portion  of  the  computer  industry,  and  therefore  DoD 
would  not  have  the  flexibility  to  capitalize  on  advances  in  computer 
architectural  technology  in  a  timely  fashion.  The  ultimate  impact 
would  result  in  DoD  very  likely  running  the  risk  of  getting  locked 
into  obsolete  architectures." 

Response:  Direct  experience  has  demonstrated  the  converse  of  this 
assertion.  Those  who  have  not  competed  have  made  a  conscious  choice 
not  to  do  so.  Far  more  qualified  bidders  have  competed  when  ISAs 
for  which  the  Government  has  unlimited  rights  were  used  as  the  basis 
for  the  procurement. 

"--DoD  would  not  be  able  to  efficiently  utilize  the  new  DoD  programming 
language  Ada  and  will  not  be  able  to  fully  capitalize  on  the  anticipated 
software  cost  savings  Ada  was  designed  to  yield." 

Response:  The  ability  to  utilize  Ada  is  not  dependent  upon  the  ISA, 
per  se.  The  question  is  compiler  and  support  software  (environment) 
availability.  It  is  more  efficient  and  economical  if  the  scarce 
national  resources  (personnel)  are  engaged  in  producing  the  best 
possible  environments  for  a  few  ISAs  than  to  partially  optimize  a 
large  number  of  them.  NEBULA  is  an  efficient  Ada  target,  despite 
claims  of  certain  companies  to  the  contrary. 

The  advantages  of  Ada  will  be  muted  if  sound  management  of  the  environ¬ 
ment  -to  -hardware  interface  (ISA)  is  not  achieved. 


"--The  three  Services  have  initiated  efforts  commensurate  with 
Instruction  5000. 5X;  for  example,  the  Army's  Military  Computer 
Family,  the  Navy's  AN/UYK-43  and  44,  and  the  Air  Force's  *17'50 
programs.  In  a  previous  report  entitled  "The  Department  of  Defense's 
Standardization  Program  for  Military  Computers --a  More  Unified  Effort 
is  Needed"  (LCD-80-69,  June  18,  1980),  we  were  critical  of  both  the 


Army  and  Navy  efforts.  We  made  the  following  statements  in  that 
report  and  believe  they  are  even  more  valid  today: 

•'***some  computer  manufacturers  are  already  designing  computers 
with  modern  arch'.tectures  that  will  have  Ada  compilers  available. 

These  or  other  manufacturers  will  probably  offer  follow-on 
computers  that  will  directly  carry  out  Ada  instructions  and  sub¬ 
stantially  improve  performance  reliability.  Because  these  changes 
provide  better  support  options,  such  as  building  more  redundancy 
into  systems,  they  should  compel  the  Department  to  further  evaluate 
the  level  of  standardization  to  be  achieved  before  allowing  the  Army 
and  Navy  to  commit  themselves  ***  for  the  long  term.  (Emphasis  added.) 

"We  view  the  need  for  architecture  standardization  as  a  function, 
in  part,  of  the  availability  of  Ada  as  the  standard  computer  programming 
language.  Because  Ada  is  being  developed  to  be  a  machine -transportable 
language  with  a  relatively  low  life  cycle  maintenance  cost,  the  need 
for  standard  architectures  may  be  diminished  when  it  is  available  ***. 
(Emphasis  added.)" 

Response:  Some  computer  manufacturers  are  indeed  producing  modern 
architectures  for  which  Ada  will  be  available.  The  direct-execution 
machine  is  not  available  and  practical  feasibility  is  yet  in  question. 

Had  GAO  completed  the  quotation  it  would  have  included: 

"...In  the  long  term,  Ada  could  become  the  standard  architecture 
when  computers  that  can  directly  execute  the  language  are  developed. 
However,  in  the  short  term,  standard  computer  architectures  are  needed 
to  reduce  life-cycle  costs.  We  believe  that  those  architectures 
should  be  common  across  Service  lines,  compatible  with  Ada  and  the 
minimum  number  required  to  meet  common  functional  requirements  and  to 
retain  the  older  languages,  such  as  CMS- 2  and  JOVIAL,  until  they  are 
phased  out.  These  measures  are  necessary  to  minimize  life  cycle  costs 
and  to  facilitate  the  transition  to  Ada." 

Truncating  the  quotation  completely  changed  the  context  and  leads  to 
misunderstanding . 
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Rola  MS E/800  vs  AN/UIK-43 

(A  and  B  versions) 

' 

Rolm  MSS/800 

AN/UYK-v  3 
(A  Version) 

AN/UYX-43 
(B  Version) 

Max  Program  Sire 
(using  virtual  memory) 

4.3  Billion 

16  Billion 

16  Billion 

Max  Physical  Size 

8.0  M  Bytes 

5.0  M  Bytes  1/ 

10  M  Bytes  1/ 

Word  Size  (bits) 

32 

32 

32 

Package  Size 

46*  x  17.5*  wide 

24  "  deep 

48*  x  If. 8*  wide 
x  22.3”  leap 

AN/unc-7  Footprint  2/ 

Same  as  AN/UYK-7 
Foot-print  only 
72"  Height  2/ 

I/O  Bandwidth  (total) 

18.20  M  Bytes/Sec 

>12.0  M  Bytes/Sec 

>24.0  M  Bytes/Sec 

Performance/Throughput 

1900  XDPS 

2500  SOPS 

4540  KQPS  - 

Cache  Size  (1C  bits) 

16  K  Bytes 

16  I  Bytes 

32  I  Bytes 

Power  (watts) (max) 

3800  Watts 

2500  Watts 

5500  Watts 

Cooling  (type) 

Air  Only 

Air/Water 

Air/Water 

•■'"BP  (hours) 

Undetermined  3/ 

>6000  4/ 

>6000  4/ 

KTTR  (minutes) 

<30  Minutes 

<15  Minutes 

<15  Minutes 

Instruction  Set 
(superset  of) 

Data  General  NV  8000 

AN/UYX-7 

AN/UYX-7 

Cost 

Approx.  $500: 

$400*  5/ 

$7501 

Software  Issues 

DG  operating  sys 
Many  ROD  compilers 
Ada  in  1983 

MTASS-L  support 

Ada  in  1985 

MTASS-L  4/ 

Ada  in  1935 

Production  Deliveries 

June  1982 

Mid-1984 

Mid-1984 

1/  The  capacity  will  grow  as  dynamic  RAM  density  increases 
2/  Fits  through  submarine  hatch  (circular) 

3/  Bolm  is  new  calculating  MTBF ,  available  in  September  1981 

4/  Although  6000  hours  have  been  specified,  ^10000  hours  can  be  expected  (according 
to  PMS-408  representatives). 

5/  AM/UYK-7  with  DDMFMs  (1981  contract)  512X 

6/  A  multi- tasking  operating  system  should  be  developed 
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DoD  Responses  to  Specific  Questions 
Regarding  Proposed  DoD  Instruction  5000. SX 


What  effect  would  Instruction  5000. 5X  have  on  the  use  of 
competition  in  the  Department  of  Defense? 

Answer:  The  objective  of  proposed  DoD  Instruction  5000. SX  is 
to  control  and  maintain  the  interface  between  MIL-SPEC  (see 
attached  definitions)  computer  hardware  and  the  software  which 
runs  on  it.  This  interface  is  termed  the  "instruction  set 
architecture"  or  ISA  of  the  computer  (a  mere  rigorous  definition 
is  given  in  Enclosure  5) .  An  ISA  may  be  „aplemented  in  hardware 
using  whatever  design  and  components,  processes,  etc.,  which  the 
producer  chooses.  DoDI  5000. 5X  lists  a  small  set  of  approved 
ISAs,  in  all  of  which  the  Government  has  unlimited  rights  (i.e., 
can  freely  use) . 

When  recent  procurements  have  been  based  upon  these  ISAs,  there 
was  a  demonstrated  increase  in  the  numbers  of  qualified  bidders 
participating.  In  the  recent  competition  for  the  Army's  Military 
Computer  Family  (MCF)  based  upon  MIL-STD-1862  or  the  NEBULA  ISA, 
there  were  12  bidders --more  than  had  been  experienced  on  any 
similar  procurement  not  based  on  ISAs  in  which  the  Government  had 
unlimited  rights. 

The  Air  Force  has  had  similar,  but  more  extensive,  experience  with 
their  procurements  based  upon  MIL-STD-1750 ,  another  ISA  on  the 
proposed  5000. 5X  list  and  in  which  the  Government  has  unlimited 
rights.  There  are  currently  23  suppliers  of  equipment  built  to 
the  MIL-STD-1750  ISA,  four  of  which  are  from  England.  Enclosure  1 
lists  these  companies.  Further,  when  MIL-STD-1750  was  used  as 
the  basis  for  the  computers  for  the  F-lll  upgrade  program,  the 
resulting  competition  allowed  the  opportunity  for  insertion  of  new 
technology  and  reduced  the  price  of  the  computers  by  almost  5C*. 
Prior  to  invoking  MIL-STD-1750,  procurements  were  sole  source  in 
many  instances,  and.  otherwise  restricted  competition  at  best. 

The  net  of  it  is  that  application  of  the  principles  of  DoDI  5000. 5X 
has  invariably  enhanced  competition  and  reduced  cost- -this  is 
demonstrated  experience  and  not  speculation  on  what  the  effects 
might  be- 


What  effect  would  Instruction  5000. 5X  have  on  the  current  computer 
industry? 

Answer:  As  noted  above,  the  instruction  encourages  and  opens  up 
competition.  On  any  given  procurement,  a  broader  section  of  the 
industry  can  compete  on  a  more  equitable  basis  than  was  possible 
under  earlier  acquisition  strategies.  Of  course,  any  given  computer 
manufacturer  may  choose  not  to  participate  because  of  a  corporate 
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philosophy  which  permits  it  only  to  market  in  an  environment 
which  minimizes  competition,  or  if  it  pe-ceived  that  the 
competitive  environment  could  negatively  effect  its  eventual 
market  share.  How  this  will  balance  out  over  time  is  yet  to 
be  determined.  Clearly,  the  proposed  instruction  will  reduce  the 
present  extent  of  sole-source  acquisitions  of  proprietary  products, 
and  that  may  be  interpreted  by  some  of  the  industry  as  negative; 
from  the  Government ' s* perspective  and  that  of  the  broader  industry 
sector,  it  must  be  viewed  as  positive. 


Would  Instruction  5000. SX  lock  DoD  into  obsolete  technology? 

Answer:  Recall  that  the  ISA  is  the  interface  between  software  and 
hardware .  Standardization  at  that  interface  has  been  demonstrated 
to  allow  and  even  encourage  the  injection  of  new  technology. 

Although  there  are  some  performance  parameters  to  be  specified  at 
that  interface,  beth  within  and  in  addition  to  the  ISA,  there  is 
essentially  transparency  at  the  ISA  to  the  implementing  technology. 
The  expert  opinion,  upheld  by  experience,  is  that  breaking  the 
sole-source  procurement  syndrome  or  its  handmaiden,  weak  competition, 
will  accelerate  the  injection  of  technology- -quite  contrary  to 
locking  the  Department  in  to  obsolescence.  That  lock-in  not  only 
to  technology  but  also  to  supplier,  is  precisely  the  lesson  to  be 
learned  from  earlier  approaches. 


Are  commercial  off-the-shelf  computers  currently  available  that 
could  satisfy  DoD's  major  needs  for  embedded  computers? 

Answer :  In  some  cases  the  answer  must  be  "yes."  And,  in  those 
cases  where  the  logistics  implications  are  tractable,  where  there 
is  no  need  for  militarization,  and  where  there  can  be  a  fair  and 
open  competition,  then  some  preference  should  be  given  to  the 
off-the-shelf  approach.  Generally,  "off-the-shelf"  means  a  common, 
commercial  product  intended  for  the  civilian  marketplace  and  one 
designed  and  produced  in  a  proprietary  way.  The  need  for  any 
change  in  the  physical  or  electrical  characteristics  of  the  machine 
will  break  the  "off-the-shelf"  model.  In  some  instances,  several 
manufacturers  could  start  with  their  proprietary  "soft"  product  and 
through  redesign  and  modification  provide  acceptable  militarized 
products --that  would  not  meet  the  essential  "off-the-shelf"  test. 
Further,  it  is  often  true  that  existing  software  must,  for  reasons 
of  economy,  schedule  or  risk,  be  accommodated.  Except  in  rare  cases, 
the  implication  is  sole-source  procurement  and  the  well-known 
consequences.  Where  those  negative  aspects  are  acceptable  in  the 
balance,  off-the-shelf  is  a  viable  acquisition-strategy  alternative 
and  should  be  so  considered.  In  no  way  can  it  be  considered  the 
predominant  method. 


Should  standardization  occur  at  ths  instruction  set  architecture  (ISA) 
level  or  at  the  higher  level  languages,  such  as  Ada? 

Answer :  Standardization  is  required  at  both  the  high  order  language 
(HOL)  and  instruction  set  architecture  levels.  HOL  standardization 
improves  the  efficiency  of  applications  code  and  the  transportability. 
ISA  standardization  is  necessary  to  allow  reuse  of  systems  and 
support  software  from  system-to-system.  Together  they  can  provide 
significant  productivity  and  economics.  Either  alone  is,  at  best._ 
a  partial  solution  to  these  problems.  Until  the  non-stop,  never-fail 
true  High  Level  Language  (HLL)  machine  is  practical  and  available., 

ISA  standardization  is  the  only  way  to  enable  application  and  system 
software  reuse.  It  should  also  accelerate  the  availability  of  Ada, 
per  se,  and,  hence,,  perhaps  hasten  the  reality  of  the  HLL  machine. 


MAJOR  FINDINGS  AND  RECOMMENDATIONS  OF  TPS  DEFENSE  SCIENCE  BOARD 
TASK  FORCE  OS  EMBEDDED  COMPUTER  RESOURCES  (SCR)  ACQUISITION  AND 

MANAGEMENT 


lm  Major  Findings 

The  controversy  over  proposed  DoD  Instruction  5000.51  is  largely  between 
interests  which  haw.  as  primary  concerns  the  procurement  of  military  embedded 
computers  and  interests  which  have  as  primary  concerns  the  operation, 
maintenance,  deployment  and  post-acquisition  support  of  these  same  computers. 
The  rhetoric  from  bcth  sides  often  neglects  the  complex  issues  inherent  in 
these  concerns.  The  situation  is  further  complicated  by  the  fact  that 
procurement  issues  are  immediate  and  measurable  in  dollars  soon,  while 
providing  a  cost-effective  deployment  and  support  environment  for  the  rest  of 
the  century  is  harder  to  quantify.  In  other  words,  the  time-frame  foci  of  the 
two  sides  in  this  controversy  are  quite  different.  The  arguments  are  further 
confused  over  the  questions: 


1.  "Should  there  be  a  standard  set  of  ISAs  at  all?" 

2.  "If  there  are  to  be  standards,  should  they  be  Government-owned  or 
Commercial  ones?" 


Embedded  Computer  Instruction  Set  Architectures  (ISAs)  should  be 
standardized.  This  action  is  necessary  if  the  Department  of  Defense  is  to 
improve  its  position  with  respect  to  (1)  software  development  costs  and, 
further,  it  is  (2)  mandatory  to  improve  the  logistic  support  and,  above  all, 
the  battlefield  sustainability  of  automated  systems. 


Given  our  finding  of  support  for  ISA  standardization.  Government  control 
over  the  ISAs  is  required.  It  is  unwise  to  commit  for  a  20-year  period  to  an 
ISA  which  can  be  changed  or  differently  supported  at  the  whim  of  a  commercial 
entity.  Too  many  considerations  of  competitive  follow-on  procurement, 
overseas  manufacture  and  ongoing  support  are  at  stake. 

ISA*  Standardization  will  affect  the  competition  for  hardware  procurements 
and  this  effect  may  be  either  positive  or  negative  in  specific  cases.  The 
Task  Force  did  not  find  the  arguments  against  standardizing  this 
software/hardware  interface  convincing  .  With  standardization  of  a  "good"  set 
of  Government-owned  ISAs,  Industry  has  the  opportunity  to  enter  competition  on 
an  equal  basis. 

Current  Service  programs  based  on  ISA  standardization  are  well  founded 
and  in  accord  with  general  policy  intent;  there  are,  however,  areas  wherein 
they  could  be  strengthened.  The  issue  of  multiple  producers  for  logistically- 
identical  hardware  is  still  an  open  question  and  one  which  deserves  more 
study. 
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High  Order  Langv-age  (HOL)  standardization  has  had  a  positive  effect  on 
software  development  and  support  costs.  Implementation  of  the  policy  to  use 
HOLs  has ,  however,  oeen  spotty. 

DoD's  Ada  Progrrm  is  well  based  and  is  proceeding  well.  The  Army's 
portion,  the  Ada  Language  System  (ALS)  should  be  strengthened  in  view  of  its 
criticality  to  the  MCF  Program  and  to  efforts  of  the  other  Services. 

DoD  Directive  5C00.29  is  the  basic  policy  document  for  automated  defense 
systems  and  we' feel  its  revision  and  update  are  urgent  matters  for  action. 
Problems  still  exist  with  regard  to  computers  ard  software  and  it  is  too  early 
to  force  this  area  into  the  routine,  oversight  pattern  afforded  to  more  mature 
technologies .  Work  Is  needed  to  rationalize  DoD  3  inconsistent  set  of 
specifications  and  standards  for  computer  resources.  Purther,  recent 
legislative  changes  must  be  promulgated  and  5000.29  is  the  proper  vehicle  for 
this. 

There  is  no  consistent  management  process  across  the  OSD  Staff  and  the 
Military  Departments  relating  to  computer  (automation)  technology.  OSD  has 
been  relying  on  a  committee  management  approach  which  was  born  of  necessity  in 
1976.  The  scope  of  automation  in  systams  and  in  their  support  has  far 
outstripped  this  approach. 


2.  RecotnaendatioE.3 


The  proposed  DcD  Instruction  50G0.5Z  be  issued.  It  should  be  reviewed 
for  consistency  with  acquisition  regulations  and  the  scope  should  be 
clarified,  e.g.,  where  does  it  apply  and  where  does  it  not.  OSD  should 
actively  manage  implementation  of  the  policy  and  control  both  the  waiver 
process  and  changes  to  the  approved  ISA  list. 

The  Military  Departments  proceed  with  current  programs— the  Army  Military 
Computer  Family  (MCI) ,  the  Navy  Tactical  Embedded  Computer  Resources  (TECR) 
Program  and  the  Air  Force  MIL-STD-1750  Program—  but  with  some  modifications: 

-  The  Army  should  Increase  the  quantity  of  Advanced  Development  Models 
(ADMs)  and/or  Full  Scale  Development  Models  (FSDMs)  of  the  MCF 
hardware  to  support  early  software  development  experience. 

-  Both  the  Army  and  Navy  reconsider  their  acquisition  strategies  to 
make  use  of  multiple  producers  of  logiatically-idcntical  computer 
hardware  if  economically  feasible. 

-  The  Air  Force  should  bound  the  number  of  unique  implementations  of 
MILT STD- 1750  with  an  eye  toward  achieving  logistic  cost  avoidance. 

-  The  Air  Force  should  consider  adding  Input /Output  specifications  and 
other,  hardware-independent  details  to  MIL-STD-1750. 

A  Senior  Policy  Official  (TJSDRE)  be  designated  and  a  more  consistent 
management  approach  be  established  across  the  OSD  staff  and  within  the 
Military  Departments.  The  first  action  has  been  taken  concurrently  with  our 
deliberations.  The  Under  Secretary  should  now: 


—  Determine  t^e  level  and  mode  of  operation  and  provide  revised 
guidance  to  the  Components  regarding  implementation  of  P.L.  97-86. 

—  Establish  a  more  uniform  set  of  S&D  objectives  and  acquisition 
policies. 

-  Provide  for  OSD  management  of  selected  generic  automation  programs, 

such  as  has  been  done  for  Ada  and  the  Very  High  Speed  Integrated 
Circuits  (VHS1C)  Programs*  - _  - 

—  Task  the  official  to  whom  this  new  policy  designation  £s  delegated 

to  be  a  principal  advisor  to  the  DSARC  on  computer  and  software 
(automation)  matters.  - 

-  Strengthen  OSD's  oversight  of  Components'  computer  and  software  R&D 
and  acquisition  activities. 

-  DoD  Directive  5000.29  be  revised  expeditiously.  It  should 
incorporate  the  changes  in  acquisition  approach  enabled  by  10  U.S.C. 
2315.  It  should  emphasize  the  ’’software-first"  approach  to  system 


design  and  development  and  should  encourage  use  of  rapid  software 
prototyping  and  competive  concept  def initio-..  Source  selection 
procedures  shoull  formally  include  software  considerations  (this  say 
require  DAS.  revisions). 

DoD  develop  and  apply  a  consistent  set  of  computer  hardware  and 
software  specifications  and  standards  across  the  Department. 

Current  work  by  :he  Joint  Logistics  Commanders  Joint  Policy 
Coordination  Sroup  for  Computer  Resource  Management  (JPCG-CRM)  may 
be  an  adequate  basis  but  DoD  should  assure  uniform  implementation  of 
the  resulting  product,  whatever  its  genesis. 

Intersystem  and  local  network  protocols  should  be  developed  from  the 
existing  DoD  standards  and  emerging  international  standards. 
Standards  for  da:a  elements  should  also  be  developed. 

# 

OSD  conduct  a  careful  review  of  the  Defense  Acquisition  Regulations 
(DAR8)  to  assure  that  they  are  in  step  with  computer  acquisition 
policy.  In  particular,  care  should  be  taken  that  time  limitations 
in  the  DARs  do  not  drive  technology  insertion  schedules  through 
misinterpretation.  The  DARs  must  not  attenuate  sharing  of 
Government-developed  applications  or  support  software. 

DoD  Instruction  5000.31  be  updated  quickly  -o  remove  outdated 
languages  and  to  add  Ada. 

The  Under  Secretary  should  assure  adequate  «.nd  continuing  support 
for  the  Ada  Joint  Program  Office  (AJPO). 

The  Service  Ada  Programs  be  strongly  supported  and  that  they 
continue  to  receive  adequate  staff  and  funds.  The  various 
components  of  this  program  should  be  batter  coordinated. 
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DEFINITIONS  PERTINENT  TO  DISCUSSION  OF  DoDI  5000 .5x 


The  Instruction  Set  Architecture  (ISA)  of  a  computer  Is  the  set  of 
instructions  (e.g.,  add,  store-into-memory)  used  to  program  a  computer, 
augmented  by  other  minimal  information  available  to  a  prograsmer  (e.g., 
interrupt  capability). 

Each  computer  has  an  ISA  which  is  the  logical  basis  for  its  physical 
structure. . 

An  ISA  may  be  implemented  in  many  different  ways  sinee  its  specification  is 
independent  of  hardware. 


An  alternative  definition  of  Instruction  Set  Architecture  is: 

"An  ISA  is  the  specification  of  the  interface  between  software  and 
hardware.  It  Includes  the  attributes  of  a  computer  as  may  be  seen  by 
a  machine  [assembly]  language  programmer  or  the  target  code  generator 
of  a  compiler  for  a  high-order  language  (HOL) .  It  describes  the 
conceptual  structure  and  functional  behavior  of  a  computer  as  distinct 
form  the  organization  of  the  data  flow  and  controls,  logic  design  or 
physical  implementation." 


MIL-SPEC  Computers  are  specially  designed  for  the  military  environment.  The 
performance  required  is  delineated,  usually,  in  a  Military  Specification  (MIL- 
SPEC)  or  Military  Standard  (MIL- STD)  which  form  an  integral  part  of  the 
contract  for  the  acquisition  of  the  specific  materiel.  MIL-SPEC  equipment  is 
generally  not  available  "off-the-shelf"  and  must  be  designed  and  fabricated 
"to  order"  to  meet  a  set  of  performance  and/or  environmental  requirements, 
including  the  form  factor  of  the  equipment.  Examples  are  space-borne 
equipment;  airborne  weapons-delivery,  navigation  or  flight-control  computers. 


Embedded  Computers  are  those  computers  incorporated  as  an  Integral  part  of, 
dedicated  to,  or  required  for  the  direct  support  of,  or  for  the  upgrading  or 
modification  of,  major  or  less-than-major  systems.  Thus  this  term  refers  not 
only  to  those  computing  devices  burled  deeply  within  subsystems  as  radars, 
radios,  missiles  and  the  like  but  more  generally  to  computers  which  are  used 
to  perform  a  portion  of  a  larger  task  such  as  fire-control,  automatic  testing, 
navigation,  and  threat  warning.  The  key  discriminator  is  whether  the 
application  is  computation  alone  or  whether  computation  is  merely  a  subtask  to 
be  performed  as  a  part  of  a  larger  activity.  In  the  Industrial  realm, 
"embedded"  computers  would  be  found  managing  process  control  in  a  steel  mi M 
or  a  chemical  plant  or  as  the  automation  element  in  an  automobile.  In  a 
hospital  or  research  laboratory,  computers  are  embedded  in  CAT  scanners,  in 
scintillation  counters ,  in  gas  chromatographs ,  in  ERG  or  EEC  equipment  —  they 
perform  specialized  and  dedicated  tasks  and  are  not,  in  general,  available  to 
support  the  general  computational  or  data  processing  needs  of  the  organization 
and  hence  are  subject  to  a  more  specialized  selection  process  than  classical 


Enclosure  5 
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Automatic  Data  Processing  Equipment  (ADFE). 

Embedded  Computer  Resources  include  the  totality  or  resources  required  for  tbe 
support  and  operation  of  “embedded  computers.**  Thus,  the  term  Includes,  but 
is  not  necessarily  limited  to: 

-  Computer  Data 

-  Computer  Hardware 

-  Computer  Programs 

« 

-  Documentation 

-  Personnel 

-  Supplies 

-  Services 
•  Training 

-  Software 


*  Support  Software 

*  Utility  Programs 

*  Test  Software 

*  Operational  (Applications)  Software 

*  Training  Software 

Tactical  Computers  are  those  used  in  the  tactical,  strategic.  Intelligence, 
cryptologic  or  command  and  control  environments  of  military  operations. 
Generally  this  would  mean  deployed  equipment  on  ships,  aircraft  or  with  the 
fielded  army  or  dedicated  to  the  training  and  support  of  military  personnel  as 
a  part  of  their  military  assignments  as  contrasted  to  the  CONUS  administrative 
support  of  the  Department,  tna  Services  or  the  Agencies.  The  term  is  even 
less  precise  than  "embedded”  and,  so,  we  prefer  not  to  use  it. 

Rnggedized  Computers  are  those  which  are  specially  designed  and  tested  to 
ensure  resistance  to  such  environmental  hazards  as  shock,  vibration,  humidity, 
ssmd,  salt,  temperature,  operational  and  storage  extremes,  altitude  and 
explosive  hazards  without  the  requirement  for  redesign  or  change  of  the 
computer  itself.  That  is  the  protection  is  provided  through  shock  mounting, 
enclosures  such  as  transit  cases,  or  other  means  to  isolate  a  fundamentally 
commercial  instrument  from  an  environment  it  was  not  basically  designed  and 
produced  to  withstand.  Some  consider  that  a  complete  mechanical  redesign 
holding  the  electrical  design  constant  constitutes  “rnggedized “  equipment; 


the  ..."routine  administrative  and  business  applications  including  payroll, 
finance,  logistics,  and  personnel  management  applications)”  are  excised.  Ther 
are  systems  in  these  applications  areas  which  fail  the  "routine”  test  as  they 
are  on  the  critical  path  toward  the  fulfillment  of  the  "military  mission.” 
Automatic  test  equipment,  deployable  logistics  systems  such  as  the  Combat 
Support  System,  NALCJMIS ,  Global  Heather  Service  systems,  the  Satellite 
Control  System,  the  1J0RAD  system.  Avionics  Intermediate  Shop  equipment,  and 
shipboard  machinery  uonitoring  systems  are  examples,  of  this  area  of 
application. 


F-16  MULTINATIONAL  STAGED  IMPROVEMENT  PROGRAM 


COL  DAVID  J.  TEAL 
DEPUTY  SYSTEM  PROGRAM  DIRECTOR 
F-16  SYSTEM  PROGRAM  OFFICE 
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1.  Welcome  to  everyone!  It  is  a  great  pleasure  for  me  to  be  able  to  tell  you  a 
little  bit  about  what  we  are  doing  on  the  F-16.  I'll  show  you  some  of  the 
things  coming  up  on  the  F-16  aircraft  which  I  think  exhibits  a  new  way  of  doing 
business.  We  are  structuring  ourselves  so  that  we  can  insert  technology  rapidly 
at  the  field  level,  and  improve  our  combat  capability  quickly  at  a  reasonable 
cost.  That's  why  we  are  excited  about  it.  I  am  also  very  grateful  to  Jeff  for 
all  the  time  he  has  put  into  organizing  this  conference  so  that  you  could  be 
here  today  to  hear  the  significant  investment  we  are  making  in  the  implementation 
of  the  architectural  standards.  We  also  must  plan  for  the  support  and  follow-on 
effort  necessary  to  sustain  the  implementation  and  modernization  of  all  the  stan¬ 
dards  as  appropriate  in  the  future.  We  would  like  to  make  all  the  tools  being 
developed  available  within  the  Department  of  Defense.  Hopefully  a  great  savings 
in  cost  and  time  will  be  realized  to  you.  That's  the  way  I  see  it  from  my  posi¬ 
tion.  That's  why  it's  important  that  we  get  together  to  exchange  this  information, 
because  it's  good  for  us  and  it's  good  for  you. 


2.  I  would  like  to  show  you  what  we  are  doing  within  the  F-16  and  why  standards 
are  a  key  part  of  this  activity.  We  are  structuring  an  architecture  for  the  F-16 
Multi-National  Staged  Improvement  Program  (MSIP),  which  will  allow  us  to  insert 
many  new  systems  on  the  F-16  over  the  next  few  years.  We  have  already  imple¬ 
mented  Stage  1,  delivered  in  November  1981.  Stage  1  consists  of  the  Group  A  pro¬ 
visions,  the  structure,  wiring  and  hard-point  changes.  The  cockpit  has  also  been 
wired.  The  idea  being  to  reduce  future  retrofit  costs  when  we  replace  our 
existing  avionics. 

3.  Stage  2  consists  of  the  "core  avionics"  which  are  the  essential  equipment 
needed  to  support  the  growth  systems.  This  stage  consists  of  a  new  cockpit 
including  a  wide  angle  raster  HUD,  up-front  communications-navigation- 
identif ication  system,  a  data  transfer  unit,  two  multifunction  displays, 
improved  radar,  radar  altimeter,  an  improved  cooling  turbine,  enhanced  fire 
control  computer,  and  advanced  central  interface  unit.  This  aircraft  is  sched¬ 
uled  for  delivery  in  July  1984. 

4.  Stage  3  is  a  continued  integration  of  systems  which  enable  us  to  fight  air- 
to-air  and  air-to-surface,  day-night,  as  well  as  in  weather.  It  includes 
internal  ECM,  provisions  for  JTIDs,  GPS,  LANTIRN,  and  BVR  missile.  A  lot  of 
thought  has  gone  into  the  structure  and  the  capability  to  incorporate  new  tech¬ 
nology  without  constantly  taking  the  aircraft  back  to  the  depot,  which  reduces 
the  number  of  aircraft  ready  for  combat. 

5.  Jovial  J-73  higher  order  language  is  being  used  to  program  the  Stage  2  core 
avionics,  and  MIL-STD-1 750A  instruction  architecture  is  being  used  as  the 
software/hardware  interface.  The  core  avionics  are  tied  together  with  a  1553 
data  bus.  Our  1553  data  bus  has  dual  protocol  1553  (USAF/F-16)  as  well  as  1553B 
capability.  MIL-STD-1760  is  being  adopted  as  the  aircraf t-to-weapon  interface. 

6.  Now,  the  good  news!  "They  haven't  yet  standardized  their  weapons." 
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7.  The  F-1 6  application  of  the  standards  started  late  in  1980/early  1981. 
However,  once  the  ball  got  rolling  things  happened  very  quickly,  thanks  to  Jeff 
and  a  lot  of  other  folks  from  the  program  office  and  General  Dynamics  who  got 
together  to  make  this  very  ambitious  and  somewhat  risky  program  work.  In  this 
particular  case,  we  are  talking  about  the  implementation  of  MIL-STD-1 750.  One 
of  the  primary  efforts  is  the  implementation  of  1750  in  a  microprocessor.  Jeff 
organized  the  first  two  forums  early  and  late  in  1981  with  the  idea  of  sharing 
our  tools  with  other  organizations  within  the  Department  of  Defense.  We  have 
progressed  in  the  development  of  these  standards  through  PDR's  and  CDR's  and  we 
are  starting  now  in  the  printed  circuit  board  developments. 

8.  The  standards  are  being  applied  to  the  central  processing  units  in  the  core 
avionics  which  will  be  programmed  in  J-73  HOL.  The  fire  control  computer, 
advanced  central  interface,  multi-function  display  set,  data  entry  cockpit 
interface  set,  and  data  transfer  unit  will  all  be  designed  to  implement  1750,  as 
well  as  operate  on  the  1553  data  bus. 

9.  All  of  the  new  LRU's  will  either  have  a  multi-card  CPU  or  use  the  1750 
microprocessor.  Also,  some  of  the  new  government  furnished  equipment,  both  the 
radar  and  HUD,  will  use  1750  and  MIL-STD-1 589.  The  existing  equipment  on  the 
F-1 6  will  remain  the  same,  i.e.,  the  INS.  However,  as  we  upgrade  and  recompete 
some  o^  these  systems,  there  will  be  opportunities  to  insert  the  standards. 

10.  I  won't  speak  for  the  managers  of  programs  outside  the  control  of  the  F-1 6 
SPO,  but  will  simply  state  that  they  are  targets  of  opportunity.  AMRAAM  repre¬ 
sents  a  very  large  market  for  the  microprocessor.  LANTIRN  will  use  the  Delco 
multicard  1750  CPU.  The  electronic  warfare  community  is  a  big  supporter  of  the 
standards  and  are  looking  very  closely  at  them  as  new  systems  come  along.  Both 
Seek  Talk  and  Combined  Altitude  Radar  Altimeter  are  potential  candidates  for  the 
standards.  Perhaps  we  can  find  a  way  for  PLSS,  CPS,  and  JTIDs  to  see  some  prac¬ 
tical  applications,  if  they  still  have  the  lead  time.  Hopefully  there  are 
representatives  here  from  those  programs  and  contractors  who  may  see  the  light  - 
get  the  religion  -  this  morning,  if  you  have  not  already  done  so. 

11.  This  is  how  we  understand  1750A.  It  is  am  'interface  standard'  and  not  a 
computer  or  an  F-*  specification,  or  a  sole  source  environment.  It  is  important 
that  everyone  understand  so  that  what  we  do  is  in  line  with  Department  of 
Defense  policy.  Once  1750  is  adopted,  an  upgrade  in  hardware  technology  will 
not  force  you  to  throw  out  all  the  old  software. 

12.  This  is  the  way  we  are  managing  the  1750  development  program.  General 
Dynamics  is  managing  the  overall  program  for  the  SPO.  They  have  defined  all  the 
specifications  per  SPO  direction  and  have  held  a  competitive  procurement. 
Fairchild  was  selected  as  the  best  over  all  solution  for  the  1750  program. 

13.  Our  program  is  a  parallel  development  effort.  Since  the  1750  micro¬ 
processor  will  not  be  ready  for  FSD,  the  Z8002  was  chosen  as  an  interim  solu¬ 
tion.  However,  the  FCC  will  have  1750  and  all  of  the  core  systems  will  be 
programmed  in  Jovial.  The  current  plan  is  to  insert  the  1750  CPU  in  place  of 
the  Z8002  prior  to  production. 


14.  As  far  as  the  HOL  goes,  the  current  F-16  uses  J3B.  It  was  a  very  success¬ 
ful  program.  It  is  a  very  good  HOL  and  very  beneficial.  We  look  forward  to 
continued  benefit  with  J73. 

15.  The  two  J73  compiler  vendors  under  contract  are  Advanced  Computer 
Techniques  and  Proprietary  Software  Systems.  ACT  is  targeting  to  Z8002  ini¬ 
tially  in  support  of  full  scale  development,  and  PSS  is  targeting  to  1750. 

Later,  both  companies  will  develop  the  alternate  target  generator.  The  initial 
deliveries  have  been  made,  look  good  and  are  on  schedule. 

16.  By  the  end  of  1982,  in  conjunction  with  the  first  flight  of  the  MSIP  flight 
test  program,  both  the  ACT  &  PSS  compilers  will  be  completed.  They  will  be  duly 
targeted  to  Z8002  as  well  as  1750A. 

17.  Thanks  for  listening.  I  hope  this  overview  gave  you  an  understanding  of 
the  application  of  avionics  interface  standards  on  the  F-16.  Let  us  know  if  we 
can  be  of  assistance  to  you.  We  welcome  your  ideas  and  suggestions. 
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RATIONAL  STANDARDIZATION  IS  INTEGRAL  PART  OF  MSIP  II 
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APPLICATION  OF  MIL-STDS  IS  A  CENTRAL  FEATURE 
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1553B 


FLIGHT  CONTROL  COMPUTER  CURRENT  CFE  ANALOG 


•16  r  nOGRAM 


'  v  ’ 


UJ 

•  <» 


m 


CN 

CO 

a 


Bl 


oo 


CO 


2 

o 


-76- 


PRODUCTION 

•  QUALIFY  THE  1750A  SYSTEM  (AND  Z8002 
IF  REQUIRED) 
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:-16  M1L-STD-1750A  MICROPROCESSOR  DEVELOPMENT  PR06RAM 


Third  Technical  Forum 
5  May  1982 


R.  K.  MOORE 


TEXT  FROM  THE  THIRD  TECHNICAL  FORUM,  5  MAY  1982 


CHART  #1 


MIL-STD-1750A  does  not  standardise  hardware,  it  standardizes 
computer  instruction  set  archi tecture.  We  are  developing  hardware 
that  may  become  a  de-facto  standard,  but  that  should  not  be 
confused  with  the  larger  issue  of  1730  standardisation.  The 
existing  1750  computers  on  the  F-16  use  a  multicard  1750 
processor — the  LANTIRN  processor  as  well  as  the  Fire  Control 
Computer  that  Delco  is  supplying.  The  chip  set  that  Fairchild  is 
developing  for  General  Dynamics  and  the  Air  Force  will  form  the 
basis  of  a  single-card  central  processor.  We  are  undertaking  the 
chip  set  development  because  the  F-16  SPO  requested  it.  The 
benefit  for  us  is  in  software  development  downstream,  but  the  big 
payoff  is  for  the  Air  Force. 


CHART  #2 


Four  MS IP  systems  are  targeted  to  use  the  1750  microprocessors 
the  advanced  central  interface  unit,  the  data  entry  cockpit 
interface  set,  the  data  transfer  unit,  and  the  multifunction 
display  set.  We  are  at  the  point  in  the  MSIP  program  where  we  are 
beginning  to  make  provisions  and  go  through  the  proposal  actions 
required  to  actually  put  the  chips  sets  into  the  equipment. 


CHART  #3 


This  is  a  little  more  detail  of  the  phased  approach  to 
introducing  the  1730.  We  are  going  through  a  full  equipment 
development  with  our  Z8000  mi croprocessors  as  the  core.  Parallel 
with  the  final  stages  of  development  and  testing  of  the 
Z8000— based  equipment  we  will  be  developing  a  single- card  1750 
processor  that's  meant  to  replace  the  card  that  houses  the  Z8000 
processor.  We  intend  to  have  full  production  capability  for  both 
1730-  and  Z8000-based  equipment. 

For  software  development  we  will  have  dual -target  Jovial 
software  tools  that  are  being  developed  for  us  by  two  suppliers. 
We  haven't  decided  how  we  are  going  to  handle  assembly  language 
software — whether  to  write  a  translator  to  go  from  Z8000  to  1750 
assembly  code,  or  start  from  scratch  and  do  the  whole  thing  over. 
The  machine-specific  test  programs  will  have  to  be  written  from 
scratch. 

The  testing  plan  is  to  go  through  full  safety-of  flight,  qual 
and  flight  test  with  the  Z8000-based  equipment,  then  phase  the 
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1750  into  the  testing  on  a  card  basis.  Our  philosphy  is  that  we 
must  test  the  equipment,  and  that  the  type  of  CPU  is  not  critical 
for  most  of  that  testing.  Therefore,  we  intend  to  demonstrate 
that  the  Z8000  cards  and  the  1750  cards  are  equivalent  as  far  as 
the  equipment  is  concerned.  We  intend  to  go  through  a  limited 
flight  test  to  verify  that  equivalency  does  exist. 

Provisions  have  been  implemented  within  all  equipments  that 
will  allow  use  of  either  the  Z8000  or  the  1750  chips.  Mr.  Henry 
Lynn  will  give  more  details  on  what  we’ve  done  along  those  lines. 
We  expect  to  make  a  decision  this  year  as  to  whether  to  go  forward 
with  full  development  of  the  1750  card.  When  I  say  decision  that 
means  GD  writing  a  proposal  and  the  Air  Force  making  a  decision. 

We  are  in  the  early  stages  of  that  proposal  effort  now. 

Production  commitment  to  1750  will  be  made  when  we  have 
demo'nstrated  that  the  two  processor  cards  are  equivalent. 


CHART  #4 


This  next  slide  is  the  schedule  for  the  mi croprocessor  program. 
I  would  like  to  show  you  a  few  things  on  this  schedule.  Notice 
that  two  CDRs  are  shown.  We  had  an  incremental  CDR.  At  the  1st 
increment  the  design  looked  very  good.  We  are  quite  satisfied, 
quite  pleased  with  the  work  that  Fairchild  had  done.  There  was  an 
open  item  at  the  conclusion  of  that  increments  the  type  of 
package. 


CHART  #5 


We  decided  that  we  did  not  want  to  use  a  64  pin  package  on 
one-hundred  mil  pin  centers.  Fairchild  has  developed  a  package 
that  is  a  64  pin  package  with  50  mil  centers.  We  did  a  lot  of 
research  and  decided  that  most  wiring  board  manuf acturers  were  not 
comfortable  with  50  mil  technology  right  now.  The  package  that  we 
ultimately  agreed  upon  is  designated  as  a  "gull -wing"  package. 

The  gull-wing  is  a  dual-in-line  package  modified  by  Fairchild  to 
be  surface  mounted.  The  pins  are  on  50  mil  centers.  We  expect 
the  printed  wiring  board  technology  to  be  the  same  as  for  a  flat 
pack.  We  plan  to  go  forward  with  the  qualification  of  this 
package,  but  the  details  have  not  been  worked  out. 


CHART  #4  (Continued* 


The  deliveries  of  the  prototype  chip  sets  and  the  engineering 
evaluation  equipment  are  shown  with  a  one  month  delay.  That  was  a 
result  of  some  extended  time  taken  earlier  in  the  program  to 
redefine  aspects  of  the  archi tecture.  The  slip  did  not  affect  the 
end  result  of  our  program,  the  preproduction  chip  sets.  However, 
as  Fairchild  progressed  further  in  the  design  and  layout  and 
actual  figures  on  the  chip  die  sizes  were  available,  we  became 
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dissatisfied  with  the  size  of  the  CPU  chip.  We  saw  that  if  we 
took  some  more  time  we  could  probably  bring  the  dimensions  down, 
and  end  up  with  a  more  producible  design,  and  feel  much  more 
comfortable  with  the  rest  of  the  program.  So  we  are  taking  some 
time  to  do  more  analysis  on  the  design  and  make  some  changes.  We 
expect  that  we  will  extend  the  schedule  once  again.  The  schedule 
that  Dan  Wilnai  will  present  will  indicate  Fairchild's  ideas  as  to 
what  the  program  should  look  like  in  the  future.  The  formal 
program  schedules  have  not  yet  been  updated.  I  wanted  to  alert 
you  so  that  when  you  see  Dan’s  presentation,  you  will  understand 
why  his  schedule  and  mine  are  different. 
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I  would  like  to  give  you  a  brief  overview  of  the  program  at  Fairchild.  You 
will  hear  much  more  detail  about  the  microprocessor  chip  set  from  Shai  Mor,  and 
you  will  hear  about  the  test  equipment  that  we  are  developing  from  Dave  Scott  of 
GD.  Ron  Byrne  will  describe  our  marketing  approach  later  in  the  day.  All  I  will 
do  is  give  you  a  general  idea  of  the  program  as  a  whole,  and  you  will  hear  the 
details  later. 

CHART  n 

Our  objective  in  the  program  is  to  develop  a  microprocessor  chip  set  comprised 
of  three  VLSI  devices.  One  of  them,  the  main  device,  is  a  single  chip  that  imple¬ 
ments  in  a  sixty-four  pin  package  the  complete  1750  instruction  set  architecture. 

It  is  the  CPU  in  the  system.  The  other  two  devices  are  support  devices.  One  of 
them  implements  the  MMU  functions  of  the  1750;  the  other  one  implements  the  block 
protect  RAM  function.  In  addition  to  that,  we  have  the  task  of  developing  test 
and  evaluation  equipment  for  the  program.  The  first  target  for  the  development 
program  is  to  deliver  fifteen  prototype  chip  sets  and  five  units  of  the  test  and 
evaluation  equipment.  Our  current  estimate  is  that  we  deliver  that  by  February  1, 
1983.  The  next  step  is  to  deliver  100  units  of  fully  qualified  preproduction  chip 
sets  by  September  1,  1983.  These  will  be  roughly  four  months  behind  the  original 
schedule. 

CHART  #3 

Fairchild  started  the  logic  design  of  the  9450  back  in  June  1981.  That  was 
long  before  we  had  any  indication  that  we  had  won  the  1750A  chip  set  development 
contract.  The  contract  was  awarded  in  mid-October  1981.  The  reason  we  started 
then  (and  we  started  on  Fairchild  funds)  was  because  of  the  tightness  of  the  sched¬ 
ule.  The  only  way  we  saw  of  getting  to  the  end  of  the  program  in  time  was  to  start 
early.  Logic  design  started  in  June  1981  and  finished  by  the  end  of  January  1982. 
We  have  taken  here  a  somewhat  aggressive  approach,  non-conventional  in  a  sense. 
Normally  in  a  microprocessor  development  you  will  finish  the  logic  design  and  only 
then  will  you  start  the  circuit  design  and  layout.  In  this  program,  because  of 
schedule  pressure,  we  started  the  circuit  design  and  layout  early.  As  you  can  see, 
we  have  finished  the  circuit  design  just  recently  and  the  first  design  is  going 
into  fab  now.  As  mentioned  earlier  we  realized  the  design  was  not  the  design  that 
we  wanted,  and  that  it  didn't  meet  our  goals;  therefore,  we  have  started  an  op¬ 
timization  effort.  The  optimization  is  centered  around  logic  design  and  layout. 

We  have  decided  to  take  this  approach  to  reduce  the  risk  in  the  program.  What  you 
see  now  is  five  iterations  of  silicon  processing.  Basically/  what  we  did  was  add 
another  iteration  of  silicon  processing.  The  first  device/ which  is  now  going  into 
fab,  will  be  a  test  device.  It  will  allow  us  to  test  the  logic  as  well  as  a  few 
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things  about  the  architecture.  The  second  iteration  will  be  a  result  of  the  circuit 
optimization  phase  of  the  program,  and  we  expect  that  to  come  out  of  fab  in  mid- 
October  1982.  At  2*s  month  intervals  after  that  we  get  the  third,  fourth,  and  fifth 
Iterations.  You  may  want  to  ask  why  we  have  elected  to  have  five  iterations.  Maybe 
it  will  work  the  first  timef  but  nobody  knows  how  many  iterations  it  will  take.  Our 
experience  has  been  that  it  takes  between  three  and  five  iterations  on,,  chip  of  this 
complexity  to  get  fully  functional  parts.  What  you  see  is  what  we  consider  to  be  a 
realistic  schedule,  maybe  on  the  pessimistic  side.  Preproduction  deliveries  will  be 
September  1,  1983. 

CHART  #4 

So  where  are  we?  Again  we  have  completed  the  design  of  the  9450,  are  going  into 
fab  with  a  testing  device,  and  are  currently  into  a  circuit  optimization  effort.  At 
the  same  time,  the  two  support  circuits,  the  9451  and  9452  are  completed  and  in  fab 
now.  The  test  equipment  development  is  on  target.  We  have  completed  the  top  level 
design  and  we  don't  expect  any  problems. 
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Chart  f  1 


MIL-STD  1750A  MICROPROCESSOR  DEVELOPMENT  PROGRAM  FAIRCHILD 

A  Schlumberger  Company 

'l 


PROGRAM  OBJECTIVES 

DEVELOP  A  HIGH  PERFORMANCE  MILITARIZED,  SINGLE-CHIP 
MICROPROCESSOR  THAT  FULLY  IMPLEMENTS  MIL-STD  1750A 
INSTRUCTION  SET  ARCHITECTURE. 

DEVELOP  SUPPORT  CIRCUITS  FOR  EXPANDING  THE  ADDRESSING 
RANGE  TO  1M  WORDS  WHILE  PROVIDING  MEMORY  PROTECTION: 

1)  MMU  -  MEMORY  MANAGEMENT  UNIT 

2)  BPR  -  BLOCK  PROTECT  RAM 

DEVELOP  TEST  AND  EVALUATION  SUPPORT  SYSTEM  BOTH 
HARDWARE  AND  SOFTWARE. 

DELIVER  15  UNITS  OF  PROTOTYPE  CHIPSETS  AND  5  UNITS  OF 
TEST  SYSTEMS  BY  FEBRUARY  1,  1983. 

DELIVER  100  UNITS  OF  PREPRODUCTION  CHIPSETS  FULLY 
QUALIFIED  BY  SEPTEMBER  1,  1983. 

D.  Wilnai 
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Chart  #  2 


PROGRAM  STATUS  -  MAY  82 


*  DESIGN  OF  THE  F9450  (1750A  CPU)  STARTED  IN  JUNE  1981; 

ARCHITECTURE  DESIGN  ’  -  COMPLETE. 

DETAILED  DESIGN  -  COMPLETE. 

TEST  DEVICE  -  IN  FAB. 

CIRCUIT  OPTIMIZATION  -  IN  PROGRESS. 

*  DESIGN  OF  F9451  (1750A  MMU)  and  F9452  (1750A  BPR)  STARTED 
IN  OCTOBER  1981; 

ARCHITECTURE  AND  LOGIC  DESIGN 
CIRCUIT  LAYOUT 
1st  SILICON 

*  ENGINEERING  TEST/EVALUATION  EQUIPMENT 

TOP  LEVEL  DESIGN  -  COMPLETE. 

s 
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Chart  #  3 


-  COMPLETE. 

-  COMPLETE. 

-  IN  FAB. 
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What  I’ll  describe  is  the  1750  chip  set  as  it  is  being 
developed  by  Fairehild.  First  I’ll  cover  the  general  1750A  chip 
set  characteristics,  then  some  basic  chip  set  configurations,  and 
then  details  on  the  three  devices  that  constitute  the  chip  set; 
namely,  the  9450  which  is  the  main  CPU,  the  9431  which  is  the  MMU 
or  Memory  Management  Unit,  and  the  9452  which  is  the  BPR  or  Block 
Protect  RAM. 


CHART  #2 


No  text  given 


CHART  #3 


This  is  the  artist  conception  of  the  full  chip  set.  There  are 
three  64  pin  packages  and  some  other  small  standard  packages.  The 
CPU  is  a  single  chip,  64  pirtipaekage  device.  The  MMU  consists  of 
the  F9431  which  is  a  64  pin  device  plus  four  standard  RAM  chips 
which  contain  the  two  maps  plus  two  bi -directional  buffers.  The 
BPR  consists  of  the  F94S2  which  is  a  64  pin  package  device,  plus 
one  standard  RAM  chip  which  contains  the  map  for  the  protection 
bits. 


CHART  #4 


A  smaller  system  which  contains  only  the  CPU  and  the  BPR  is 
shown  here. 


CHART  #5 


Now  let  me  go  through  the  character! sties  of  the  system 
starting  with  the  CPU.  The  CPU  is  a  single  64  pin  microprocessor 
which  implements  M1L-STD-1750A.  It  requires  a  single  five  volt 
supply  plus  an  injector  current.  The  technology  used  is  I3L-II 
which  is  basically  a  bi -polar  technology.  I3L  has  the  advantages 
of  being  bi -polar— in  otherwords  high  speed— wi  thout  the 
disadvantages  of  high  power  and  low  density.  Another  feature  of 
the  technology  which  is  inherent  in  bi -polar  is  high  radiation 
tolerance.  The  chip  is  fully  static  with  a  maximum  clock 
frequency  of  20  Megahertz.  All  of  the  inputs  and  outputs  are 
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compatible  with  low  power  Schottky.  We  have  on-chip 
multi -processing  capabilities  as  will  be  explained  later. 


CHART  »6 


A  basic  goal  of  the  program  has  been  to  develop  a  high 
performance  chip  that  is  fast  over  the  entire  military  temperature 
range.  For  the  F9450  we  are  talking  about  200  nanoseconds  for  a 
register  to  register  add. and  1.8S  microseconds  for  a  16  x  16 
multiply.  The  F9450  handles  single  and  double  precision 
arithmetic  and  provides  16  general  purpose  registers  as  defined  in 
MIL-STD-1730A.  The  full  complement  of  32  and  48-bit  floating 
point  instructions  as  defined  In  the  standard  have  been 
implemented  on  chip.  The  chip  is  designed  for  real  time 
processing  environments  and  has  16  levels  of  interrupt  vectors, 
also  as  defined  in  the  standard.  The  chip  can  directly  access  64 
thousand  words  of  memory;  with  the  MMU  the  system  can  access  up 
to  one  mega-word.  Two  programmable  timers  are  also  implemented 
on-chip. 


CHART  #7 


The  BPR  is  providing  the  function  of  write  protection  in 
physical  memory  for  the  CPU  and  DMA  in  IK  blocks.  The  BPR  is 
implemented  using  the  F94S0,  a  gate  array  used  internally  within 
Fairchild.  The  gate  array  was  used  to  reduce  development  time. 
The  other  chip  required  to  implement  the  BPR  is  a  standard  RAM 
chip  which  will  contain  the  protection  bits. 


CHART  #8 


The  MMU  provides  a  translation  from  logical  to  physical 
►  addresses  for  both  instructions  and  operands.  It  increases  the 

addressing  space  to  one  mega-word.  Protection  is  accomplished  in 
blacks  of  4K  words  in  basically  three  modest  (1)  access  key- 
matching  the  lock  to  the  key;  (21  write  protect—  applies  for 
data  accesses;  and  (3)  execute  protect—  applies  for  instruction 
fetches.  The  F9480  gate  array  was  again  used  for  the  main  block 
of  the  logic  to  shorten  the  design  cycle.  Four  RAM  chips  contain 
the  address  maps.  Two  bi-directional  buffers  were  necessary  to 
allow  use  of  a  gate  array  package  with  only  64  pins,  as  I  will 
explain  later. 


CHART  #9 


This  is  the  logic  symbol  for  the  F9450 — the  CPU.  The  F9430  is 
a  64-pin  chip.  Shown  are  the  16-bit  multiplexed  bus  and  all  the 
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status  lines  and  handshake  signals  necessary  -for  bus  and  I/O 
cycles,  the  bus  control  and  arbitration  signals,  abort  and  normal 
power-up  discretes,  reset,  the  CPU  clock  and  the  timer  clock,  the 
trigger-go  reset  discrete,  the  eight  status  lines —  access  key  and 
address  state—  which  are  neccessary  -For  MMU  operation,  the 
external  -fault  inputs,  and  the  nine  external  interrupts.  There 
are  -five  pins  -for  supply:  Vce,  two  injector  pins,  and  two  ground 
pins.  One  pin  is  not  connected. 


CHART  #10 


This  is  the  logic  symbol  -for  the  F9431  —  the  main  element  o-f 
the  MMU.  The  le-ft  side  o-f  the  diagram  illustrates  the  signals 
that  inter-face  with  the  CPU:  the  in-formation  bus  (IB),  the  -four 
AK’s.and  the  -four  AS's,  and  all  the  status  and  handshaking 
signals.  On  the  right  side  most  o-f  the  signals  interface  with  the 
four  local  RAM  chips  that  contain  the  maps  for  the  instruction  and 
data  spaces.  The  RAL  and  E/W  lines  are  the  output  that  comes  back 
from  the  rams —  both  the  access  lock  and  the  execute-  or 
write-protect  bit.  BOE  controls  the  bi-directional  buffers  that 
are  part  of  the  MMU  system,  but  physically  reside  outside  the 
9431.  the  memory  protect  error  goes  back  to  the  CPU  fault  inputs, 
the  ADD  VAL  output  signals  the  memory  subsystem  and  the  BPR  that 
the  extended  address  coming  from  the  MMU  system  is  valid.  The 
SPEED  input  allows  the  user  to  select  the  response  speed  of  the 
MMU,  i.e.  the  number  of  wait  states  inserted  by  the  MMU. 


CHART  #11 


This  is  the  logic  symbol  for  the  F9432—  the  major  element  of 
the  BPR.  the  signals  on  the  left  side  of  the  symbol  are  basically 
those  signals  that  interface  to  the  CPU  and  the  MMU  if  present. 

The  signals  in  the  upper  right  interface  to  and  control  the  local 
RAM  that  contain  the  protection  bits.  In  the  case  of  a  memory 
write  protect  violation  ,  the  memory  protect  error  output  will 
signal  the  CPU  to  report  the  fault  and  the  memory  system  to 
inhibit  the  write.  Global  protect  enable  is  an  output  that  tells 
the  rest  of  the  system  that  no  memory  location  can  be  written  into 
since  the  BPR  will  not  have  been  initialized.  After  the  BPR  has 
been  initialized  by  the  CPU,  and  the  bits  in  the  local  RAM  have 
been  loaded,  global  protect  enable  will  be  deactivated.  The  last 
set  of  pins  are  the  ABORT  input  coming  from  the  CPU)  DMA 
acknowledge, si  nee  the  BPR  must  distinguish  between  memory  accesses 
by  the  CPU  and  DMA;  the  address  valid  input  coming  from  the  MMU; 
and  two  speed  pins  that  do  a  job  similar  to  the  speed  pins  in  the 
MMU,  letting  the  BPR  know  how  many  wait  states  to  insert  depending 
upon  the  speed  of  the  CPU  clock. 


CHART  #12 
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This  is  a  system  conf iguration  consisting  of  a  CPU  and  an  MMU. 
The  MMU  consists  of  all  the  logic  contained  within  the  broken 
line. 

CHART  #13 


This  is  a  system  con-figuration  consisting  o-f  a  CPU  and  a  BPR. 
Note  that  if  an  MMU  is  not  present,  four  bits  of  the  extended 
address  must  be  tied  to  ground  and  four  bits  must  come  from  the 
information  bus. 


CHART  #14 


this  is  a  system  that  contains  all  the  elements  of  the  chip 
set:  the  CPU,  the  MMU,  and  the  BPR.  Note  that  the  memory  protect 

error  signals  are  tied  in  a  WIRE-OR  so  that  either  the  MMU  or  the 
BPR  can  report  an  error. 


CHART  #13 


This  chart  shows  a  few  features  of  I3L-II  tecnology.  I3L  is  a 
bipolar  technology.  As  opposed  to  TTL  which  is  based  upon  a 
multiple-input,  single-output  transistor,  I3L  transistors  are 
single-input,  multiple-output.  Minimum  gate  delays  are  2.5 
nanoseconds  or  less,  with  typical  gate  delays  of  4  nanoseconds  for 
the  four  collector  configuration  at  100  microamps  of  injector 
current  per  cell.  Packing  density  is  300  to  600-  gates/mm2 
including  power  and  interconnect.  The  intrinsic  density—  active 
devices  only—  is  about  double.  The  technology  is  directly 
interfaceable  to  TTL.  This  feature  is  used  on  the  F9450  since 
part  of  the  chip  is  TTL.  As  mentioned  the  technology  is  fast  and 
dense,  and  it  makes  implementation  of  standard  cells  such  as  PLA’s. 
and  ROM*  s  relatively  easy.  Being  bipolar,  the  technology  allows* 
operation  over  the  full  military  temperature  range.  Also  the 
technology  is  scalable  for  improved  performance  and  density. 


CHART  #16 


The  indicated  subjects  will  be  covered  in  the  following 
discussion  of  the  CPU. 

CHART  #17 


The  data  types  are  as  defined  in  MIL-STD-1750A. 


CHART  #18 
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The  addressing  modes  are  as  defined  in  MIL-STD-1730A. 


CHART  #19 


This  is  art  internal  block  diagram  of  the  CPU.  There  are  five 
major  blocks*  (1)  the  Address  Processor,  <2)  the  Data  Processor, 
(3)  the  Interrupt  Processor,  <4>  the  Microprogrammed  Control 
Section,  and  (5)  the  Timing  and  Bus  Arbitration  Unit.  The  Address 
Processor  is  responsible  for  generating  all  of  the  addresses  that 
go  out  from  the  CPU  during  bus  cycles,  either  instruction 
addresses  or  operand  addresses.  The  two  basic  registers  included 
in  the  Address  Processor  are  the  IC,  or  Program  Counter,  and  the 
MAR,  or  Memory  Address  Register.  An  i ncr emen ter/ deer emen ter 
implied  within  the  block  allows  the  next  operand  address  or 
instruction  address  to  be  prepared  while  executing  some  other 
operation  in  the  Data  Processor.  The  Data  Processor  block  is  the 
part  of  the  chip  the  does  the  data  processing.  The  main  part  of 
the  block  is  the  ALU.  A  17-bit  ALU  was  required  because  of  the 
multiply  algoritm  used.  The  ALU  is  fast  with  carry  look-ahead. 

The  shifter  shifts  left  and  right  and  is  also  capable  of 
byte-shifting,  sign-extend,  and  things  of  that  nature.  The 
register  file  which  is  contained  within  the  Data  Processor  block 
consists  of  the  16  general  purpose  registers  that  are  user 
accessable,  plus  another  seven  scratchpad  registers,  some  of  which 
are  also  shift-registers.  The  Data  processor  also  includes  the 
status  register  and  the  two  timers  as  defined  in  MIL-STD-1730A. 

I  mentioned  two  timers  are  working  on  separate  clocks.  These 
are  real  time  timers  and  obviously  they  should’ t  rely  on  the  main 
CPU  clock.  On  the  otherhand  to  be  able  to  read  the  counter  while 
counting,  the  two  clocks  have  to  be  synchronized.  On  chip  we 
synchronize  the  timer  clock  with  the  main  CPU  clock.  We  can  do  a 
clean  read  of  the  timer  while  the  timer  is  still  counting.  So, 
while  the  timer  is  independent  as  far  as  counting  the  time  from 
the  CPU  clock,  it  is  still  synchronized  to  allow  a  read  while 
counting.  We  put  a  lot  of  effort  in  trying  to  multiply  as  fast  as 
possible,  and  what  we  use  is  a  modified  Booth  algorithm  which  is 
doing  two  shifts  past  that  and  cutting  in  half  the  time  that  a 
normal  add/shift  algorithm  produces.  To  implement  the  algorithm 
we  needed  another  shifter.  If  you  are  familiar  with  the  Booth 
algorithm,  you  have  to  add  the  multi pi lean  shifted  by  two,  and 
some  extra  logic  to  cover  the  subtle  cases  of  overflow  that  result 
in  this  type  of  operation.  As  you  can  see  the  data  processor 
besides  getting  two  operands  and  producing  results  is  also 
generating  the  different  ALU  conditions  necessary  for  the  control 
section  to  do  branches. 

The  next  block  is  the  interrupt  proceessor,  and  this  block 
receives  the  interrupt  and  faults,  and  is  responsible  for 
processing  these.  To  do  that  it  contains  three  major  subblocks 
and  these  are  the  three  registers*  the  PIR  register,  which 
records  all  the  interrupts  coming  in  whether  from  the  inside  the 
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chip  or  outside  the  chip.  The  Mask  register  which  is  deciding 
which  of  the  interrupt  are  masked  and  which  is  not.  The  'fault 
register  which  receives  the  external  and  internal  faults.  Some  of 
the  external  faults  are  synchronized,  like  the  memory  protect 
error  and  some  of  them  are  non-synchroni red.  So  some  of  them  had 
to  be  implemented  as  an  edge  sensitive  fault.  Also,  included  in 
that  block  is  the  priority  logic  that  looks  at  the  PIR  and  the 
mask.  In  case  of  several  interrupts  happening  at  the  same  time, 
it  determines  which  one  is  going  to  get  serviced  according  to  the 
priority  that  I  will  present  in  a  few  minutes.  Also  included  in 
that  block  is  the  enable  logic  controlled  by  executing  an  XIO 
instruction  that  says  interrupts  enable  or  disable.  The  other 
block  is  the  microprogram  control  section.  It's  a  two  level 
pipeline  microprogram  section  generating  the  control  bits  for  the 
rest  of  the  processor,  and  it  also  includes  the  source  and 
destination  logic.  As  you  know  the  two  operands  selected  from  the 
data .processor  could  come  either  from  the  instruction  body  (the 
way  they're  defined  in  the  insturction  format)  or  from  the 
microprogram.  If  you  want  to  work  between  two  scratchpad 
registers  obviously  it  would  not  come  from  the  instruction 
format.  The  logic  that  looks  at  that  part  of  the  instruction 
register  and  selects  where  the  source  for  the  two  operands  being 
worked  on  in  this  particular  cycle  is  in  that  block.  The  last 
block  is  the  timing  and  bus  arbitration  unit.  This  is  the  block 
that  gets  the  CPU  clock,  which  is  up  to  20MHs,  generating  all  the 
internal  clocks  and  strobes  necessary  to  activate  any  of  these 
blacks  and  it  is  also  responsible  for  the  handshaking  with  the 
bus.  Two  things  which  are  obvious  to  the  user  are  the  STRBA  and 
the  STRBD  which  come  out  of  that  section.  STRBA  is  covering  the 
time  that  the  address  is  on  the  bus  and  STRBD  covers  the  time  the 
data  is  on  the  bus.  The  bus  is  the  multiplex  bus.  Part  of  the 
status  register  is  those  eight  bits  of  address  state  and  address 
key  that  go  into  the  MMU. 


CHART  #24 


This  is  the  F9430  register  set 


CHART  #27 


In  the  system  there  are  three  types  of  timing  cycles:  a  three 
state  cycle  for  a  pure  ALU  cycle.  The  four  state  cycle  is  the 
minimum  memory  bus  cycle  to  I/O  and  memory,  if  no  wait  states  are 
inserted  at  20  Mhz  it  needs  200  nanoseconds.  Wait  states  are  used 
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as  required  for  slower  memory  to  access  data.  The  five  state  cycle 
means  that  conditions  during  the  cycle  require  the  next 
microaddress  to  be  contingent  upon  conditions  in  the  machine. 

This  cycle  is  also  used  in  the  abort  cases.  So  there  are  three, 
four  and  five  state  cycles  which  at  20  Mhz  mean  150,  200  and  250 
nanoseconds. 


CHART  #28 


This  is  what  happens  during  the  minimum  read  bus  cycle.  The 
CPU  clock  is  shown  along  with  the  internal  states  S0,  SI,  S2  and 
so  forth.  Bus  request  is  the  first  thing  that  is  generated  when 
you  want  to  start  a  bus  cycle.  If  the  bus  grant  is  granted  at  the 
same  time  then  the  CPU  has  control  over  the  bus  and  begins  it’s 
bus  qycle.  Once  it  gets  the  bus  it  pulls  down  the  bus  busy  line 
to  signal  that  this  is  when  the  cycle  starts.  Once  the  CPU  gets 
the  bus  it  will  output  the  three  status  lines:  mem/io,  read/write, 
data/ instruction.  As  long  as  the  CPU  does  not  have  the  bus  these 
lines  and  most  others  are  tri-stated.  Bus  lock  is  used  if  the  CPU 
does  not  need  to  lock  the  bus  then  it  follows  exactly  the  bus 
busy.  You  lock  the  bus  when  you  want  to  for  example,  read  and 
then  write  to  a  certain  location.  STRBA  indicates  when  the  bus 
holds  an  address,  and  the  trailing  edge  is  used  to  latch  the 
address  into  a  373  type  device.  RDYA  is  pulled  low  when  you  want 
Vi  to  insert  wait  states,  in  this  case  none  are  inserted  since  this 

is  a  minimum  cycle.  RDYD  acts  the  same  as  RDYA  to  insert  wait 
states  when  the  data  is  not  ready.  the  bus  has  two  phases: 
address  phase  and  then  data  phase.  The  times  shown  are 
preliminary,  since  chips  have  not  been  fabricated  yet. 


CHART  #29 


Similar  to  the  previous  slide  is  the  minimum  write  cycle,  the 
only  difference  is  the  extended  time  when  the  data  is  on  the  bus 
which  is  used  to  accomidate  the  slower  CMOS  memories  that  are 
available.  To  insert  wait  states  onto  the  data  phase  of  the  bus 
cycle  you  pull  this  low  and  another  wait  state  is  inserted. 


CHART  #30 


The  same  thing  occurs  during  the  minimum  write  bus  cycle, 
similar  to  the  previous  slide.  To  extend  the  address  the  RDYA 
signal  must  be  used  and  an  SI  state  is  inserted. 


CHART  #31 


This  simplifies  explanation  of  the  RDYD  signal  in  a  bus  cycle. 
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CHART  #32 


The  RDYA  signal  polarity  and  setup  times  are  shown. 


CHART  #33 


This  shows  what  happens  during  a  bus  arbritaration  cycle.  The 
CPU  pulls  the  bus  request  low  telling  the  arbritor  it  needs  the 
bus.  If  the  bus  arbritor  grants  the  bus  to  the  CPU  it  pulls  the 
bus  grant  low.  As  long  as  the  CPU  does  not  have  the  bus  it  is 
tri -stated.  The  arbritaration  is  done  on  a  CPU  clock  cycle  basis. 


CHAR t  #34 


Some  multi -processor  con-figurations  are  shown.  First  the  CPU 
and  a  DMA  device  are  on  the  bus  with  the  DMA  device  having  the 
highest  priority.  You  need  a  -flip-flop  and  a  gate  that  receives 
the  DMA  Enable  from  the  CPU.  The  bus  grant  is  synchronised  with 
the  CPU  clock. 


CHART  #33 


With  two  CPUs  the  scheme  is  very  similar  to  the  previous  slide. 
We  arbitrarily  assign  one  of  the  CPUs  a  higher  priority.  It 
issues  the  request  and  receives  the  grant,  and  the  other  one  gets 
the  grant  bar.  It  is  again  synchronised  to  the  CPU  clock. 


CHART  #36 


With  up  to  eight  bus  masters,  we  have  a  priority  encoder.  It 
is  a  direct  extension  of  the  two  CPU  scheme. 


CHART  #37 


There  are  six  fault  inputs  to  the  CPU,  three  are  synchronous 
and  are  latched  into  the  fault  register  on  the  trailing  edge  of 
bus  busy.  The  other  three  are  asynchronous  and  edge  sensitive  and 
labeled  SF0,  SF1,  and  SF2. 


CHART  #38 


The  fault  register  is  a  sixteen  bit  register  defined  by  the 


-104- 


S.  MOR 

TEXT  FROM  THE  THIRD  TECHNICAL  FORUM,  S  MAY  1982 

standard.  Any  bit  set  in  the  fault  register  causes  the  level  1 
interrupt  to  occur. 


CHART  #39 


There  are  two  sub-cl assif i cations  of  error  conditions  that  are 
called  major  error  and  unrecoverable  error.  Unrecoveralbe  errors 
have  to  do  with  instructri ons,  and  when  one  occurs  we  can  not 
continue.  It  causes  an  abort  and  forces  an  interrupt  level  0  to 
occur.  Major  errors  will  cause  an  abort  also,  but  these  do  not 
cause  a  level  0  interrupt. 


CHART  #41 


This  is  the  priority  scheme  orginization  with  a  linkage  and 
service  pointer  for  each  interrupt. 


CHART  #42 


The  console  operations  are  built  in  on  chip.  The  console 
request  input  signals  when  we  want  to  do  a  console  operation.  By 
reading  an  I/O  address  the  particular  console  operation  is 
decoded.  The  console  represents  to  the  CPU  three  1/0  addresses: 
one  command  address  and  two  data  addresses. 


s.  mor 

TEXT  FROM  THE  THIRD  TECHNICAL  FORUM,  3  MAY  1902 


CHART  #47 


The  self  test  is  part  of  the  initialization  routine  that  is 
invoked  by  tha  rasat  pin.  Tha  sal f  tast  raads  and  writes  to  tha 
registers,  verifies  tha  various  ALU  and  pre-ALU  functions,  chacks 
tha-  booth  hardMara,  shifter,  tha  ROM  constants,  IC  and  MAR  ara 
chackad.  Than  a  synthatic  instruction  is  ganaratad  and  executed 
to  tast  tha  IR  and  and  associated  logic.  If  an  error  is 
encountered  bit  13  in  tha  fault  register  is  sat  and  tha  normal 
power  up  will  not  be  sat. 


CHART  #48 


This  is  tha  initialization  routine  that  occurs  on  power-up. 

CHART  #49 


This  is  tha  rest  of  the  initialization  routine,  part  of  which 
is  the  self-test.  After  that  wa  read  the  configuration  register 
which  tells  us  tha  chip  set  configuration  for  initialization 
purposes. 

CHART  #30 


Performance  is  calculated  by  a  program  written  by  Jack  Herllin 
Tha  total  throughput  is  683  KOPS  for  tha  DAIS  avionics  mix.  Usin 
only  fixed  point  wa  get  1.3  MIPS,  floating  point  only  is  180  KOPS 
If  an  MMU  is  attahead  wa  gat  about  600  KOPS. 
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CHART  #51 


What  I  vast  to  describe  now  Is  the  way  ve  plan  to  implement  the  built-in  func¬ 
tions.  To  refresh  the  memory  of  people  who  might  have  forgotten,  the  1750A  standard 
definition  of  a  built-in  function  opcode  basically  serves  as  an  escape  code.  If  we 
allow  user  defined  types  of  operations,  for  example,  if  someone  wants  to  Implement 
the  sine,  cosine  or  any  other  transcendental  functions,  this  is  what  he's  going  to 
use.  Now  the  way  we  propose  to  do  it  is  using  the  9450  together  with  another  chip 
that  is  in  an  advanced  stage  of  development  at  Fairchild,  the  9443,  which  is  an 
IEEE  floating  point  standard  coprocessor.  To  accommodate  the  9450,  the  9443  has 
now  two  modes  of  operation:  IEEE  mode  and  1750  mode.  I  will  go  over  very  briefly 
how  the  43  works.  The  43  is  basically  a  slave  processor.  It's  not  a  real  copro¬ 
cessor  looking  at  the  IB  and  the  instruction  stream  and  intercepting  its  own  in¬ 
structions.  The  way  it  works  is  as  a  slave.  It  has  to  receive  from  the  CPU,  the 
command  and  the  starting  address  for  its  operand,  if  it  happens  to  be  a  memory  type 
operation.  So  9443  is  what  we  call  a  coprocessor  or  slave  processor.  We  are  pre¬ 
senting  to  the  CPU  four  I/O  addresses,  and  it  is  treated  by  the  CPU  as  four  I/O 
devices.  One  I/O  address  presents  the  starting  operand  address.  The  CPU  is  cal¬ 
culating  the  starting  address  of  the  operand  for  the  particular  floating  point 
operation  ve  want  to  execute;  for  example,  sine  or  cosine.  If  that  particular 
operation  does  not  involve  a  memory  operation  then  this  is  not  calculated  by  the 
CPU,  and  obviously  not  sent  out  to  the  coprocessor.  Then  you  have  a  control  reg¬ 
ister  which  presents  another  I/O  address  to  the  CPU,  and  it  specifies  things  like 
rounding  mode.  If  you  are  familiar  with  IEEE  floating  point,  you  know  there  is  a 
lot  to  specify.  What  is  Important  in  our  case  is  that  it  tells  the  1750  and  9443 
whether  its  going  to  be  IEEE  mode  or  1750  floating  point  mode;  so  that's  the  con¬ 
trol  register.  Then  the  instruction  register  presents  another  I/O  address  to  the 
CPU  which  is  where  the  instruction  originates,  and  it  also  cells  the  43  what  opera¬ 
tion  to  do;  sine,  cosine  or  whatever.  The  status  register  is  what  the  CPU  is  read¬ 
ing  from.  The  coprocessor  and  for  exasqile,  faults  are  registered  in  the  status 
register.  The  43  has  eight  internal  registers  in  the  single  precision  or  four 
extended  precision.  All  operations  for  the  43  either  register  to  memory  or  register 
to  register.  There  is  no  memory  to  memory  in  the  43.  If  its  a  memory  operation, 
then  the  43  gets  Che  starting  address  from  the  CPU  and  then  goes  ahead  and  fetches 
its  operand  from  memory.  In  other  words,  it  becomes  another  bus  contender.  It  has 
to  request  for  the  bus  Ilka  any  other  CPU  or  EMA  device  or  whoever  is  hung  on  the 
bus.  Once  it  gets  its  starting  address,  its  control  register  data  and  instruction 
register,  the  43  goes  ahead  and  executes  independently  the  instruction.  When  the 
execution  is  completed,  the  two  lines  from  the  43  signal  back  to  the  CPU  either 
completion  or  fault.  These  two  can  be  interrogated  by  1/0  polling  or  the  user  can 
generate  an  interrupt  using  them.  The  43  maybe  further  interrogated  by  executing 
1/0  instructions.  For  example,  if  one  of  the  BIF  instructions  chat  was  sent  to  the 
coprocessor  was  illegal,  it  will  be  reported  in  the  status  register. 
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This  is  an  illustration  of  what  the  9443  represents  to  the  CPU.  Actually  the 
43  has  32  bit  addressing  capabilities  but  in  our  case  we  don't  use  it,  we  use  only 
the  AL  register.  Shown  here  are  the  control  register,  instruction  register,  and 
status  register. 

CHART  lit  53 

This  is  the  way  the  BIF  instruction  looks  in  our  1750  implementation.  As  you 
can  see  its  a  three  word  instruction.  And  if  you  ignore  the  last  word,  it  looks 
like  a  normal  direct  memory  or  indexed  memory  instruction.  The  4F  is  defined  in 
the  MIL-STD,  and  considering  the  way  the  9443  works,  only  the  Indicated  addressing 
modes  make  sense.  Since  the  9443  is  expecting  addresses  there  is  no  point  in  using 
immediate  type  of  addressing.  Bit  8  specifies  Indexed  or  non- indexed  operation, 
and  the  register  is  specified  in  Bits  12  through  15.  This  is  the  same  way  the 
specification  is  done  in  the  normal  1750  instructions.  Actually  the  same  DODA 
routines  are  used  in  the  microcode.  IR  is  the  Instruction  that  we  want  to  execute 
on  the  coprocessor.  The  instruction  is  read  into  the  CPU  and  sent  back  to  the  co¬ 
processor;  thus  there  is  a  three  word  instruction  format.  Another  feature  that  we 
have  added  here  is  the  ability  to  talk  to  four  coprocessors  with  one  1750  instruc¬ 
tion.  The  two  bits  10  and  11  specify  which  coprocessor  the  instruction  refers  to. 

CHART  #54 


These  are  the  configurations  in  which  the  9443  will  work  with  9450.  The  first 
configuration  is  without  an  MMU.  As  you  can  see  the  9443  is  one  of  the  bus  con¬ 
tenders  in  the  system,  and  it  has  to  be  arbrltrated  just  like  any  other  bus  con¬ 
tender.  In  the  case  of  an  MMU  system  the  9443  has  to  supply  its  own  AS&AK  to  be 
able  to  operate  through  the  MMU.  These  are  not  included  as  part  of  the  9443; 
therefore,  we  need  an  external  device  that  is  addressed  as  an  I/O  device  by  the 
9450.  Other  aspects  of  the  operation  are  basically  the  same. 

CHART  055 


This  is  the  sequence  of  events  that  occur  when  a  BIF  instruction  is  occurring. 
The  CPU  is  calculating  the  effective  address  according  to  the  normal  1750  procedure. 
If  the  coprocessor  is  not  present  than  an  illegal  operation  is  signaled  and  the 
operation  is  terminated.  If  the  coprocessor  is  present,  then  the  CPU  will  use  the 
three  I/O  addresses  to  send  to  the  9443  the  starting  address,  and  two  other  ad¬ 
dresses:  the  instruction  that  you  want  to  execute  and  the  control  register.  In 
the  case  of  1750  the  major  thing  the  control  register  will  tell  the  9443  is  to  go 
to  the  1750  mode,  rather  than  the  IEEE  mode.  The  note  explains  once  again  that 
the  control  register  and  the  coprocessor  AS/AK  latch  are  loaded  separately  using 
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CHART  #55  (Cont’d) 

XIO  instructions.  There  was  no  point  making  these  operations  part  of  the  built-in 
function  instruction  format  because  it  would  make  a  four  word  format  and  the  opera¬ 
tions  are  seldom  used.  The  9443  is  a  very  high  performance  device  with  floating 
point  operations  on  the  order  of  two  or  three  microseconds  for  a  multiply  or  divide 
in  single  precision. 

CHART  #56 

The  last  two  sections  of  the  presentation  have  to  do  with  the  MMU  and  the  BPR. 

I  will  go  over  the  functions,  how  the  functions  were  implemented,  some  word  about 
timing,  the  pinout,  and  system  configuration. 

CHART  #57 

The  function  of  the  MMU  is  to  translate  logical  addresses  to  physical  addresses 
and  extend  the  addressing  space  to  one  million  words.  There  are  two  address  maps, 
one  for  the  instruction  space  and  another  for  the  data  space.  Each  is  256  x  16 
registers.  Another  feature  of  the  MMU  is  memory  protection.  There  are  three  modes 
of  protection;  the  first  is  access  key  protect  in  which  the  AK  coming  from  the  CPU 
is  matched  against  the  lock  four  bits  in  the  appropriate  register  and  if  a  mismatch 
occurs  a  memory  protect  error  is  generated.  If  we  are  in  the  data  mode  there  is  one 
bit  that  tells  us  whether  we  are  allowed  to  write  into  the  associated  4K  block  of 
memory.  The  same  bit  is  used  in  the  Instruction  fetch  mode  to  tell  us  whether  we 
are  allowed  to  fetch  from  that  4K  block. 

CHART  #58 

This  is  a  familiar  slide  showing  AS&AK  coming  from  the  CPU.  The  AS  is  select¬ 
ing  a  page  group.  The  four  most  significant  bits  of  the  IB  select  one  register  from 
the  page  group  and  the  PFA  coming  out  is  concatenated  with  the  twelve  least  signi¬ 
ficant  bits  from  the  IB  to  generate  the  twenty  bits  of  physical  address. 

CHART  059 

The  MMU  was  implemented  using  what  looks  like  a  one  register  cache.  The  assump¬ 
tion  is,  using  the  principle  of  locality  of  accessing,  that  if  we  accessed  a  4K  block 
it  would  be  more  than  reasonable  to  assume  that  the  next  access  to  memory  would  be 
from  the  same  4K  block.  So  we  have  on  chip  two  register  caches;  one  for  the  data 
section  and  one  for  the  instruction  section.  If  we  get  an  address  coming  out  of  the 
CPU  that  is  identical  to  the  previous  address  contained  in  the  latch,  then  we  go 
ahead  to  the  data  register  and  use  it.  If  we  get  a  miss,  we  access  the  external 
RAM  maps.  Statistically,  we  will  get  hits  probably  90%  of  the  time. 


-109- 


SHAI  MOR 

TEXT  FROM  THE  THIRD  TECHNICAL  FORUM,  5  MAY  1982 

CHART  #60 


This  chart  indicates  the  MMU  timing.  If  we  ignore  the  time  it  takes  to  execute 
an  XIO  instruction  to  and  from  a  register  in  the  map,  we  look  at  this.  If  we  get  a 
hit  then  we  incur  two  additional  wait  states.  If  we  get  a  miss  then  the  MMU  is  in¬ 
serting  four  additional  wait  states  because  it  has  to  access  the  map,  bring  back  the 
access  lock  and  the  protection  bits  in  the  PPA.  So  statlscally  there  should  be  some¬ 
thing  like  2.2  wait  states.  That  is  what  we  use  in  our  performance  calculations. 


CHART  #63 


This  slide  illustrates  that  the  CPU/MMU  combination.  Let  me  emphasize  that 
when  we  talk  about  MMU  we  are  talking  about  seven  chips.  The  main  chip  is  in  a  64 
pin  package  which  is  called  the  9451.  There  are  six  external  chips.  Four  of  the 
chips  are  commercially  available  RAM  chips  which  contain  the  two  maps.  Instruction 
and  data.  Two  are  bi-directional  buffers  which  are  also  commercially  available 
products.  The  MMU  also  outputs  the  three  reserve  bits  which  currently  are  not 
used  for  anything. 

CHART  #64 


The  final  section  addresses  the  BPR:  functions,  implementation,  timing,  pinout 
and  system  configuration. 
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CHART  if 65 

The  BPR  functions  are  to  provide  write  protection  in  the  physical  address  space 
for  the  CPU  and  the  DMA.  The  protection  is  done  in  IK  pages  as  opposed  to  the  4K 
pages  as  done  in  the  MMU.  The  BPR  also  provides  global  write  protection,  in  other 
words,  nothing  can  be  written.  This  is  done  when  the  system  is  powered  up  because 
before  the  RAM  is  initialized  and  the  protection  bits  are  set,  everything  must  be 
globably  protected.  After  the  BPR  is  initialized  then  global  protection  goes  away 
and  protection  is  accomplished  according  to  the  contents  of  the  RAM. 

CHART  //66 

.  l*his  chart  shows  what  the  RAM  looks  like.  In  the  case  where  we  have  an  MMU  we 
have  two  sets  of  64  registers;  one  set  for  the  CPU  and  one  for  the  DMA.  Each  bit 
in  the  register  represents  IK  of  physical  memory.  So  if  a  particular  bit  is  set  to 
one,  it  means  that  this  IK  is  write  protected.  In  the  case  where  we  do  not  have  an 
MMU  then  the  addressing  space  is  significantly  smaller  and  it  contains  actually  two 
sets  of  four  registers  each,  and  again  each  bit  is  representing  IK  of  physical 
memory. 

CHART  if  67 


In  the  BPR  implementation  we  used  a  similar  concept  to  what  we  did  in  the  MMU 

and  it  actually  applies  even  more  here.  Because  here  if  we  read  in  one  register, 

we  have  protection  for  16K  so  the  likelyhood  of  getting  a  page  boundary  crossing 

is  even  smaller.  Again  we  have  a  comparator  and  if  the  current  address  matches  the 

previous  one,  then  we  don't  have  to  go  to  the  external  RAM.  If  we  get  a  miss  then, 
similar  to  the  MMU,  we  go  ahead  and  read  the  appropriate  16  bit  register  from  the 
RAM  and  do  the  protection  only  then.  Obviously  this  will  take  longer.  To  minimize 
the  number  of  external  chips  and  considering  that  in  the  time  that  we  do  a  BPR  XIO, 
mainly  loading  a  register  in  the  BPR,  reading  one  from  it  is  not  critical  at  all. 
What  we  chose  to  do  is  use  only  one  RAM  chip  and  doing  the  loading  and  reading  in 
two  bytes  of  eight  bits.  Therefore,  we  don't  need  two  external  RAMS;  we  can  only 
use  one. 

CHART  #68 

This  diagram  shows  how  the  RAM  is  connected  to  the  BPR.  All  the  control  is 
coming  from  the  BPR. 

CHART  #69 

This  is  the  impact  of  the  BPR  on  timing.  The  critical  figure  that  we  have  to 
look  at  is  this  one  here.  As  you  can  see  its  again  two  wait  states  inserted  by 
the  BPR  if  we  get  a  miss.  The  BPR  and  MMU  are  working  at  the  same  time,  so  only 
if  we  get  a  miss  will  the  wait  states  be  serial.  If  we  get  a  hit,  the  wait  states 
will  be  in  parallel.  So  there  are  no  extra  wait  states  iu  90%  of  the  cases  when 
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CHART  #69  (Cont'd) 

we  connect  the  BFR  and  MMU  at  the  same  time.  The  rest  of  the  cases  are  not  critical. 
Again  we  have  the  two  pins  into  the  BPR  that  control  the  speed;  namely  determining 
how  many  wait  states  are  going  to  be  added  by  the  BPR,  and  it  depends  on  the  CPU 
clock. 


CHART  #72 

This  slide  has  already  been  shown.  Shown  are  the  interface  of  the  CPU,  the  RAM 
controls,  the  memory  protect  error  that  goes  back  to  start  the  fault  sequence  if  we 
get  a  protect  error.  This  is  the  global  protect  enable  which  is  a  separate  pin  that 
disables  any  writing  to  the  memory  before  the  BPR  is  initialized. 

CHART  in  3 

This  is  a  system  consisting  of  the  CPU,  MMU  and  BPR.  There  is  nothing  new  to 
say  in  addition  to  what  I've  already  said  except  that  as  you  can  see  the  memory 
protect  error  is  a  tie  of  the  signals  from  the  BPR  in  the  MMU,  and  if  either  device 
is  signaling  a  memory  protect  error  the  fault  register  will  be  loaded  and  the  fault 
sequence  will  start. 


1750A  CHIP  SET 


1750a  chipset  characteristics 

1750A  CHIPSET  configurations 

F9450  -  1750A  CPU  -  TECHNICAL  DESCRIPTION 

F9451  -  1750A  WIU  -  TECHNICAL  DESCRIPTION 

F9452  -  1750A  BPR  -  TECHNICAL  DESCRIPTION 
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1750A  CHIPSET 


F9450:  I750A  CPU 

msi:  I750A  MEMORY  MANAGEMENT  UNIT  (MMU) 

F9452:  1750A  BLOCK  PROTECT  RAM  (BPR) 
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Chart  #  4 
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*  ...  * 


F9450  (1750A  CPU) 


*  SINGLE  64-PIN  MICROPROCESSOR.  IMPLEMENTS  MIL-STD 
1750A  INSTRUCTION  SET  ARCHITECTURE. 

*  SINGLE  5V  SUPPLY  (ADDITIONAL  INJECTOR  CURRENT  SOURCE 
REQUIRED)  -  POWER  DISSIPATION  LESS  THAN  3  WATTS 

*  I3L-II  (3  MICRON)  TECHNOLOGY  WITH  10**5  RADIATION 
TOLERANCE. 

*  STATIC  OPERATION  WITH  CLOCK  FREQ.  0-20  MHZ. 

*  LOWER  POWER  SCHOTTKY  INPUT/OUTPUT. 


*  MULTIPROCESSING  CAPABILITIES. 
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HIGH-PERFORMANCE  OVER  MILITARY  TEMPERATURE  RANGE  (200  ns 
ADD;  1.85  ps  16  x  16  MULTIPLY). 


SINGLE  AND  DOUBLE  PRECISION  ARITHMETIC  (16  AND  32  BITS). 

•  • 

16  GENERAL  PURPOSE  REGISTERS. 

32  AND  48-BIT  FLOATING  POINT  ARITHMETIC  IMPLEMENTED  ON 
CHIP. 

REAL-TIME  PROCESSING  WITH  16  LEVELS  OF  INTERRUPT  VECTORS. 

DIRECTLY  ADDRESS  64K  WORDS,  EXTENDABLE  TO  1M  WORDS  WITH 
MMU. 

TWO  PROGRAMMABLE  TIMERS. 
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BPR  FEATURES 


i 

PROVIDES  WRITE  PROTECTION  IN  PHYSICAL  MEMORY 
FOR  CPU  AND  DMA  IN  PAGES  OF  IK  WORDS 

i 


UTILIZES: 

-  F9480  GATE  ARRAY  CHIP 

-  93479  RAM  CHIP 


I 

i 


a 


■ 
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WU  FEATURES 


*  PROVIDES  LOGICAL  TO  PHYSICAL  ADDRESS  TRANSLATION 

FOR  INSTRUCTIONS  AND  OPERANDS  • 

*  IN  WORD  ADDRESSING  SPACE 

•  PROTECTION  IN  LOGICAL  SPACE  OF  4K  WORD  PAGES  FOR: 

•  • 

-  ACCESS  KEY 

-  WRITE 

-  EXECUTE 

•  UTILIZES: 

-  F9A80  GATE  ARRAY  CHIP 

-  A  93A79  RAM  CHIPS 

-  2  54F2A5  BIDIRECTIONAL  BUFFERS 
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A  II  TECHNOLOGY  FEATURES 


-  Minimum  gate  delay  of  2.5ns  and  better 

-  Avg.  gate  delay  4ns  (min.  size  f*o«4)  at  100  JSfr  cell  current 

-  Packing  density  500-600  gates/mm^  including  rower  and 
INTERCONNECTS  AND  1200  GATES  1mm2  INTRINSIC  DENSITY 

-  Direct  TTL  interface  capability 

-  Fast  and  dense  conventional  circuitry  i.e.  PLA's,  ROM, 

RAMs  on  same  chip 

-  Mil.  grade  temp,  operation 

-  Scalable  for  improved  performance  and  density. 
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*  Data  types 

*  Addressing  modes 

*  Block  diagram 

*  Register  model 

*  Pin-out 

*  Timing  diagrams 

*  Multiprocessing  (bus  arbitration) 

*  Interrupts  and  Faults  handling 

*  Console  operations 

*  Initialization  and  self  test 

*  Performance 

*  BIF  Implementation 
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DATA  TYPES 


1)  Bits 

2)  Bytes  (8  bits) 

3)  Word  (s  6  bits) 

4)  Double  Words  (32  bits) 

5)  Single  Precision  Floating  Point  (32  bits) 

6)  Extended  Precision  Floating  Point ’(^8  bits) 
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ADDRESSING  flODES 


REGISTER  DIRECT 
MEMORY  DIRECT 
MEMORY  DIRECT  INDEXED 
MEMORY  INDIRECT 

MEMORY  INDIRECT  WITH  PREINDEXING 

IMMEDIATE  LONG 

IMMEDIATE  SHORT 

IMMEDIATE  SHORT  POSITIVE 

IMMEDIATE  SHORT  NEGATIVE 

IC  RELATIVE 

BASE  RELATIVE 

BASE  RELATIVE  INDEXED 
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F9450  BLOCK  DIAGRAM 
5  MAIN  BLOCKS  W/ INTERFACE  SIGNALS 
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TIMING 


The  Timing  Unit  generates  three  types  of  nano/miero 
cycles  according  to  the  following: 


*  a)  A  3-state*  cycle  for  pure  ALU  nano/miero 
control  words . 

b)  A  4-state  cycle  for  a  nano/micro  control 
word  with  a  bus  request. 

c)  A  5-state  cycle.  This  applies  to  those 
nano/micro  words  where  the  address  of  the 
next  nano  control  word  is  conditionally 
determined  by  the  result  conditions  of 
the  current  ALU  cycle. 

The  5-state  cycle  also  applies  to  those 
bus  cycles  that  follow  any  cycle  where  a 
fault  causing  an  Abort  Condition  has 
occured. 


A  state  is  equal  to  one  CPU  clock  period. 
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Chart  #  36 


EXTERNAL  FAULTS: 


Synchronous  Fault  inputs  (latched  by  trailing  edge 
of  BUS  BUSY  signal) 

*  Memory  Protect  Error 

*  Memory  Parity  Error 

*  External  Address  Error 


Asynchronous  Fault  inputs  (edge  sensitive) 

*  System  Fault  0 

*  System  Fault  1 

*  System  Fault  2 
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Chart  #  37 
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FAULT  REGISTER  (FT)  5 


The  Fault  Register  is  16  bits  wide. 

Bit  0  CPU  memory  rpotect  error 
Bit  1  Non-CPU  memory  protect  error 
Bit  2  Memory  parity  error 
Bit  3  Spare 
Bit  A  Spare 

Bit  5  Illegal  I/O  address 
Bit  6  Spare 
Bit  7  System  Fault  0 
Bit  8  Illegal  memory  address 
Bit  9  Illegal  instruction 
Bit  10  Privileged  instruction 
Bit  11  Address  State  error 
Bit  12  Spare 

Bit  13.  BITE  (Built-in  test)  or  System  Fault  1  or  2 
Bit  14  System  Fault  1 
Bit  15  System  Fault  2 


Any  bit  set  in  the  Fault  Register/  will  cause  a 
Machine  Error  (P1R,  bit  1).  s.  nor 
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Chart  #  38 
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ABORT  CONDITIONS: 


UNRECOVERABLE  ERRORS: 


*  Illegal  Instruction 

*  Instruction  Protect  Fault 

*  Instruction  Parity 

*  Instruction  Illegal  Address 

*  Address  State  Fault 


MAJOR  ERRORS: 

*  Privileged  Instruction 

*  CPU  Access  Mode 

*  CPU  Write  Protect 

*  CPU  Data  Illegal  Address 

*  Illegal  I/O  Address 
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(Bex) 


Power  Down  (cannot  be 
Basked  or  disabled) 

Machine  Error (cannot 
be  disabled) 

User  0 

Floating  Point 
Overflow 

Fixed  Point  Overflow 

Executive  Call  (cannot 
be  aasked  or  disabled) 

Floating  Point  Underflow 

Timer  A 

User  1 

Timer  ,B 

User  2  " 

User  3. 

Input/Output  Level  2 

User  4 

Input/Output  Level  2 
User  S 


NOTE*  Interrupt  number  0  has  the  highest  priority.  Priority  decrease 
with  increasing  interrupt  number. 
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CONSOLE  SEQUENCE 


CONSOLE  REQUEST 


COMPLETE  . 
-INSTRUCTION 


READ  CONSOLE  COMMAND 
(IOR  CYCLE) 


EXECUTE  SPECIFIED 
CONSOLE  OPERATION1 


WAIT  FOR  NEXT 
CONSOLE  REQUEST 


(1)  Reading  and  writing  to  the  console  is  done  using  I/O  cyc.es. 
Addresses  are: 


•  Console  command  :  8400 

•  Console  read  address  :  8401 

•  Console  write  address  :  0400 
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SELT  TEST  (SIT) 


INVOKES  BY: 

“  The  power-up  (initialisation)  routine 

>  .. 

SELF  TEST  FUNCTIONS: 

-  Keada/vritea  all  registers  in  register  file 

"  Causes  fault  and  verifies  that  the  fault  bit  is  aet 
and  a  machine  error  interrupt  is  pending 

-  Verifies  ALU  and  pre-ALU  functions 

“  Checks  booth  hardware  bp  performing  a  multiply 
“  Cheeks  divide  hardware  by  performing  a  divide 
“  ALU  shifter  is  checked  right/left  by  booth/divide 

-  Verified  BOM  constants  can  be  accessed 

“  Verified  1C /MAR  can  be  accessed  and  incremented 

-  Generates  an  instruction  (using  a  BOM  constant). 
Loads  it  into  IB  and  executes  it,  to  check  a  full 
path  through  the  control  section. 

ERRORS  IN  BH: 

~  Set  bit  13  in  the  fault  register 

-  Normal  power  up  will  not  be  set 
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INITIALIZATION  FUNCTIONS 
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I 


I 


•  -  •  . 


4 


9443  OFBtATXOH 


jriprtinti  4  I/O  idirmti  to  the  CPU 


-  Start in*  operand  addreaa  (Address  rtgiittr) 

-  control  resister  (specifies  round in*  mode. 
XEEX/1750A  format  end  ao  forth) 

-  Inatrnction  resistor 

-  Status  resister  (contains  exceptions  end  Faults* 
one  of  them  is  illessl  9443  OF) 


There  ore  8  internal  resisters  in  sinsle  precision  or  4 
resisters  in  double  (extended)  precision* 

the  9443  operations  are  memory  to  resister  (destination 
may  be  memory  or  resister).  or  resister  to  resister* 

In  memory  operations,  the  9443  mill  feteh  its  operands 
from  memory  (usins  the  start ins  address  supplied  by  the 
CPU).  The  number  of  memory  accesses  depends  on  the 
instruction  and  precision  mode* 

Once  the  9443  s**s  its  AI.  Cl*  II  resist era  loaded  it  mill 
bid  for  the  bus  (if  one  of  the  operands  is  in  memory) 
usins  tb*  S*a***l  arbitration  scheme*  .  . 

Upon  completion  of  its  operation,  the  9443  mill  activate 
one  of  its  2  pins  that  indicate  completion*  One  indicates 
completion  without  faults,  and  the  other  indicates  faults* 

These  pins  may  be  polled  (usins  10  insructions)  or  used 
for  interrupts  to  the  CFU* 

«/ 

the  9443  may  be  further  interrosated^to  the  nature  of  the 
faults/  by  readins  (usins  10)  its  status  resister* 
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9W  REGISTERS  REPRESENTATION  IN  I/O  SPACE 
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Chart  #  52 


BIF  INSTRUCTION  FORMAT 


7  8 


10  11  12 


15 


COPR. 


Rx 


Displacement  (A) 


Instruction  (IR) 


Available  1750A  Addressing  modes: 


1)  Memory  Direct  (D): 

2)  Memory  Direct  Indexed  (Dx): 

3)  Memory  Indirect  (I): 

A)  Memory  Indirect  Indexed  (lx): 


[A] 

ft  +  (Rx)]  |  1  ■ 0 

r<A)]  | 

fft  +  (Rx)]]  \  1  ’  1 


COPR.  H-.  SELECTS  ONE  OF  FOUR  POSSIBLE  COPROCESSORS 
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B1F  SEQUENCE 


BEGIN 

Calculate  effective  address  (EA)  using  the  normal  BODA; 
jf  Coprocessor  not  present  then  signal  illegal  op  and 

TERMINATE 

ELSE 

BEGIN 


Calculate  1/0  address  according  to  coprocessor 
number;  send  (IOVI)  EA  to  coprocessor  AL 
REGISTER  (1/0  ADDRESS  0800  FOR  COPROCESSOR  #0); 
Read  next  word  (IR); 

Send  (I0W)  IR  to  coprocessor  instruction 
REGISTER  (1/0  ADDRESS  0801  FOR  COPROCESSOR  #0) 


END 


NOTE:  The  coprocessor  control  register  (CR)  that  is  selecting 

1750A  format  in  the  9443,  and  the  coprocessor  AS/AK 

REGISTER  (EXTERNAL  LATCH)  ARE  LOADED  SEPARATELY  FROM 
THE  9450  USING  XI 0  INSTRUCTIONS. 
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Chart  #  55 


F9451 


1750A  WU 


o 


Functions 

Implementation 

Timing 

Pin-out 

System  configuration 
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Chart  #  56 


m  FEATURES 


LOGICAL  TO  PHYSICAL  ADDRESS  TRANSLATION 
ADDRESSING  SPACE  OF  1M  WORDS  (2©  »«r  addr) 
2  MAPSs 

1)  Instruction  Map  (2s 4  *  it) 

2)  Operand  Map  (2*4  *  u») 

PROTECTION  IN  LOGICAL  SPACE  OF  AK  PAGES 
FOR  THE  FOLLOWING; 

1)  Access  Key  Protect 

2)  Write  Protect 

3)  Execute  Protect 
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MU1  MMU  (LOCK  OUttWAM 
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F9452 


1750A  BPR 


Functions 

Implementation 

Timing 

Pin-out 

System  configuration 
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Chart  #  64 


bpr  functions 


*  WRITE  PROTECT  OF  PHYSICAL  CPU  MEMORY 

*  WRITE  PROTECT  OF  PHYSICAL  DMA  MEMORY 

*  PROTECTION  IS  DONE  ON  IK  PAGES 

*  PROVIDES  GLOBAL  WRITE  PROTECT  .FROM 
INITIALIZATION  UNTIL  IT  IS  ENABLED 
(by  an  XIO  Instruction) 


-164- 


S.  Mor 

Third  Technical  Forum 
5  May  1982 

Chart  #  65 


S.  Mor 

Third  Technical  Forum 
5  May  1982 

Chart  I  67 


-166- 


S.  Mor 

Third  Technical 
5  Hay  1982 

Chart  #  68 


WAIT  STATES 


NEEDED  IN  ADDRESS  PHASE: - 
(Valid  STRBA  time) 


NEEDED  IN  DATA  PHASE :- 
(Valid  STRBD  time) 


Freq  range 
(MHZ) 

15-233 

12-15 

8-12 

LESS  THAN  8 


READ 

~T~ 

0 

0 

0 


MEMORY 


WRITE 

0 

0 

0 

0 


OTHERS 


0  6 

0  4 


0  4 

0  2 
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F-16  MIL-STD-1750A  MICROPROCESSOR  DEVELOPMENT  PROGRAM 
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CHART  l 1 


I  have  cried  to  anticipate  some  of  the  questions  that  you  might  have  about 
how  you  can  apply  this  microprocessor  in  your  own  system.  Consequently,  I  have 
broken  it  down  like  this:  I  will  go  through  the  overview,  the  electrical  inter¬ 
face,  clocks  and  timers,  the  faults,  interrupts,  bus  control  philosophy, 
specification  of  the  memory  I/O  bus,  memory  system  design,  and  the  I/O  system 
design. 

CHART  n 


As  an  overview,  you've  noticed  that  the  CPU  clock  goes  to  all  the  components 
of  the  chip  set  and  must  go  to  the  bus  arbitor  as  well.  The  CPU  clock  synchronizes 
all  the  sigtnals  in  the  chip  set  that  are  local  to  the  CPU  card.  Because  o£.the 
multiplexed  memory  I/O  bus,  there  is  a  choice  of  memory  interface  systems  that  can 
be  designed  using  this  microprocessor.  You  can  keep  the  multiplex  memory  I/O  and 
extend  the  address  phase  of  the  cycle.  Or  you  can  demultiplex  the  bus  as  it  comes 
off  the  CPU  and  transmit  the  address  bus  in  parallel  with  the  data  bus.  A  change 
in  the  specification  16ZE181,  which  will  be  in  the  new  specification,  will  take 
the  bus  arbitot  out  of  the  CPU  and  place  it  in  the  external  system.  We  do  not 
believe  this  presents  an  undue  burden  to  the  whole  system  and  we  show  you  ways 
to  solve  that. 

We  define  the  interrupts  to  be  edge  triggered  and  we'll  talk  about  the  faults 
that  generate  the  machine  error  interrupts. 

CHART  #3 

Our  view  of  the  microprocessor  chip  set  is  as  three  functional  groups  of  com¬ 
ponents  -  the  CPU,  the  memory  management  plus  its  peripheral  support  and  the 
block-protect  RAM.  These  components  were  specified  to  interface  in  this  manner 
with  a  minimum  amount  of  additional  logic  needed  to  make  the  chip  set  work.  The 
bus  arbitor,  which  was  formerly  part  of  the  chip  set,  is  brought  out.  We  found 
out  that  in  architecturing  different  types  of  buses,  it  was  hard  to  get  one  type 
of  bus  arbitor  to  do  all  the  functions.  The  bus  arbitor  is  now  out  in  the  system 
where  the  user  can  tailor  it  for  his  specific  application. 

CHART  H 


When  the  block-protect  RAM  operates  with  the  CPU  as  is  the  case  in  the  F-16, 
the  extended  address  bus  inputs  to  the  block-protect  RAM  are  split  into  two 
groups.  The  four  least  significant  bits  go  down  to  the  memory  I/O  bus  where  the 
block-protect  RAM  will  latch  the  most  significant  bits  of  the  address  bus,  as 
they  come  out  of  the  CPU.  Zeroes  are  inserted  on  the  four  most  significant  bits. 
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CHART  #5 


This  is  a  revised  block  diagram  of  the  CPU.  In  this  I've  split  off  the 
system  faults  which  are  the  asynchronous  inputs  to  the  fault  register  and  chosen 
to  call  those  machine  error  interrupts.  That's  because  functionally  they  do  act 
like  interrupts.  They're  edge  triggered,  like  the  normal  interrupts  and  they 
all  OR  their  bits  together  to  make  a  single  machine  error  interrupt.  The  bus 
control  signals  in  the  memory  7./0  bus  will  be  discussed  in  turn. 

CHART  l 6 


On  the  MMU  there  are  two  special  signals  -  the  ready  address  which  goes  to 
the  CPU  and  the  memory  protect  error  which  goes  to  the  CPU  and  the  memory  system. 
Both  are  open  collector  type  functions  for  OR  tieing. 

CHART  in 


Similarly  the  block-protect  RAM  has  the  same  type  of  open  collector  outputs 
on  it.  These  outputs  are  designed  to  work  with  IK  pull-up  resistors.  Next, 

CHART  8 


The  question  came  up,  what  about  the  power  requirements  and  what  about  signal 
interface  requirements? 

CHART  #9 


These  are  power  requirements  expressed  in  watts.  The  5  volt  TTL  part  of  the 
CPU  at  CDR  looked  like  1.3  watts  total  power.  There  was  1  amp  of  injector  current 
at  a  nominal  1.3  volts.  That  is,  a  current  type  input  and  not  a  voltage  type 
input,  so  this  1.3  watts  must  be  supplied  by  another  power  source.  You  can  bleed 
current  from  the  5  volt  power  supply  if  you  can  stand  the  3.7  watt  loss  in  the 
external  resistors.  Normally,  you  would  provide  a  current  source  to  drive  that 
input.  The  MMU  has  a  very  high  power  dissipation  because  of  the  bipolar  RAMs 
and  TTL  that  interface  with  it.  The  gate  array  part  of  the  chip  set  is  very  low 
in  power  and  was  less  than  .2  watt  total  injector  power  at  1.3  volts.  The  block- 
protect  RAM,  because  it  doesn't  have  as  many  TTL  parts  associated  with  it,  is 
expected  to  be  about  1.1  watts  out  of  the  5  volt  supply  and  less  than  .2  watt^out 
of  the  1.3  volt  supply.  These  specifications  cover  operation  from  -55  to  125 
case  temperature. 

CHART  #10 

• 

What  about  interface  drive?  It's  bipolar,  it's  TTL  compatible.  You  can 
break  the  signals  down  into  three  groups  -  the  three  state  signals,  the  uni¬ 
directional  inputs  and  outputs,  and  the  open  collector  signals.  This  tends  to 
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CHART  #10  (CONT'D) 

tie  all  those  signals  together  on  one  interface  chart.  The  inputs  are  specified 
as  800  microamps  max  load  for  logic  zero,  40  microamps  for  logic  one,  using  true 
logic.  Output  sink  8  milliamps  and  supply  400  milliamps  at  2.4  volts.  The 
leakage  of  the  tri-state  in  the  open  collectors  is  expected  to  be  about  the  same 
as  normal  TTL  gates. 

CHART  #11 


OK,  about  the  clocks  and  timers  used  in  the  chip  set. 
The  CPU  clock  frequency  is  selected  by  the  application. 
CHART  #12 


The  CPU  design  as  Shai  pointed  out  is  completely  static.  It  will  run  from 
DC  and  is  designed  to  go  to  20  megahertz.  Internal  state  changes  with  the  CPU 
take  place  on  the  low  to  high  transition  of  the  clock.  20  megahertz  is  the  design 
maximum  operating  frequency  and  at  that  frequency  you  must  be  very  careful  about 
your  clock  symmetry  requirements  because  the  components  in  the  chip  set  will 
require  a  minimum  pulse  width  high  and  low  of  20  nanoseconds. 

CHART  #13 


Shai  told  you  that  the  timers  are  counting  asynchronously  with  a  100  kilo¬ 
hertz  clock.  The  100  kilohertz  must  be  supplied  by  your  system.  Because  of 
power,  ye  changed  from  the  4  megahertz  input  which  is  in  16ZE181  down  to  100 
kilohertz.  The  100  kilohertz  is  sampled  by  a  signal  internal  to  the  micro¬ 
processors.  This  is  to  make  sure  that  the  timer  will  have  settled  out  by  the 
time  it  needs  to  be  read  if  the  microprocessor  is  doing  an  I/O  operation  with 
one  of  the  timers.  That  way  we  can  assure  data  consistency. 

CHART  #14 


The  external  scale  to  divide  down  20  megahertz  to  the  100  kilohertz  is  just 
a  couple  of  components  in  conventional  TTL  and  was  not  considered  to  be  an  undue 
burden  to  the  implementor. 
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CHART  #15 

Ok,  the  trigger  go  counter  is  a  general  purpose  counter  in  1750  which  is  not 
specified  to  have  any  period  length  or  any  particular  count  format.  What  1750 
does  provide  is  an  XIO  command  to  reset  the  timer.  That  command  is  explicitly 
decoded  by  the  CPU  and  comes  out  as  a  pin,  and  may  be  used  to  reset  the  trigger 
go  counter.  Now  in  1750  it  says  it  also  sets  an  output  discrete.  On  F-16  we 
use  the  trigger  go  counter  output  as  a  software  timing  fault  generator,  and  take 
it  back  to  the  system  zero  fault  input  on  the  central  processing  unit. 

CHART  #16 


Which  leads  right  into  faults. 
CHART  #17 


Some  faults  are  detected  in  the  chip  set  and  some  of  them  must  be  detected 
cooperatively  by  the  CPU  with  the  whole  system.  The  CPU  on  its  own  can  detect 
illegal  instructions,  priviledged  type  instruction  errors,  built-in  test  errors 
at  power  on,  or  address  state  faults.  All  of  those  are'explicit  and  well  defined 
in  the  specification.  The  MMU  will  detect  the  memory  protection  violations  which 
are  two  types  -  the  access  violations  and  the  execute  write  protect  violations. 
Block-protect  RAM  if  used  will  detect  memory  write  protect  violations  using 
separate  maps  for  the  CPU  and  the  DMA. 

CHART  #18 


Because  it  is  impossible  for  the  microprocessor  to  know  in  advance  how  much 
memory  will  be  in  any  particular  application,  we  ask  the  whole  system  to  do  the 
illegal  address  decoding  for  memory  addresses.  And  also,  using  the  same  rationale 
we  don't  know  which  XIO  commands  will  be  implemented  in  the  user  system.  We  ask 
the  host  system  to  figure  out  which  commands  are  legal  for  the  system  and  which 
commands  are  illegal  for  the  system. 

Optional  fault  detection  is  built  into  the  fault  register  with  hooks  for 
memory  parity  error.  The  software  fault  time  out  in  the  F-16  turns  out  to  be 
system  zero  machine  error  interrupt.  The  two  system  BITE  interrupts  set 
BITS  14  and  15,  respectively,  of  the  fault  register  and  also  set  BIT  13. 

CHART  #19 


There  are  exactly  three  machine  error  interrupts  feeding  the  fault  register. 
There  are  other  internal  detected  events  which  show  up  in  the  fault  register  that 
also  cause  machine  errors.  Six  spare  inputs  in  1750  are  allocated  to.thtf  user 
to  define,  as  he  will,  and  two  are  left  for  interrupt  expansion. 
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CHART  020 


All  the  Interrupts  ha\e  similar  characteristics,  that  is,  they  are  all 
asynchronous  to  events  that  are  going  on  inside  the  CPU.  We  have  elected  to  make 
them  edge  triggered  and  they  are  detected  on  the  low  to  high  transition  of  the 
signal  input.  And  also  because  we  recognize  that  edge-triggered  things  are 
susceptible  to  noise,  they  are  received  on  the  CPU  by  hysteresis  gates  for  extra 
noise  immunity. 

CHART  #21 


Machine  interrupts  or  faults,  if  you  will,  and  the  BITS  that  they  affect  in 
the  fault  register  are  defined  by  this  table.  BIT  7,  the  system  fault  zero,  is 
a  software  fault  time  out  on  the  F-16.  System  fault  1  and  system  fault  2  set 
BITS  14  and  15  and  according  to  the  standard  also  set  BIT  13.  This  is  interrupt 
level  one.  It  is  maskable  but  cannot  be  disabled. 

CHART  # 22 


The  user-defined  interrupts  and  their  levels  are  specified  by  1750. 
CHART  #23 


The  expansion  interrupts  in  the  standard  are  called  I/O  level  1  and  I/O 
level  2  and  come  in  the  interrupt  priority  on  fixed  levels,  namely,  12  and  14. 
The  interrupt  pins  on  the  CPU  are  there.  The  rest  of  the  hardware  that  must  be 
added  to  make  it  conform  to  MIL-STD-1750  is  shown  on  the  next  chart. 

CHART  #24 


We  have  a  pseudo-schematic  of  very  large  priority  encoder  taking  up  to  256 
inputs,  generating  an  8  bit  code.  Any  expansion  interrupt  sets  an  interrupt 
level  to  the  CPU.  The  CPU  in  turn  responds  to  that  by  going  out  with  the  16  bit 
address  which  is  the  input/output  code  register,  and  gets  those  bits  onto  the 
but  which  correspond  to  highest  priority  interrupt. 

CHART  #25 

Ok,  a  little  bit  about  bus  control.  Bus  control  has  been  generalized  a 
little  bit.  One  of  the  things  bus  control  does  here  that  it  wouldn't  normally 
do  is. control  synchroni.  tion.  We'll  show  you  some  simple  bus  arbitors. 
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CHART  #26 

The  bus  arbicor's  function  of  course  is  to  control  access  to  the  global 
memory  I/O  bus.  Another  function  is  to  synchronize  control  signals  for  use  by 
the  MMU  and  th  BFR,  because  when  the  DMA  is  going  on,  the  CPU  is  tri-state  and 
essentially  not  active.  It  is  sitting  there  recording  faults  occurring  on  the 
bus.  We  have  made  the  function  of  synthesizing  the  address  strobe  for  non- 
multiplexed  bus  applications  part  of  the  generalized  bus  arbitor. 

CHART  #27 

Looks  fearsome,  it  has  lots  of  inputs  and  outputs  and  this  is  the  memory 
interface  over  here.  On  the  CPU  side  is  the  DMA  enable/disable  1  CPU  Busy,  Bus 
Lock.  The  CPU  reqeust,  as  Shai  pointed  out,  is  only  used  in  multiprocessor 
applications.  In  a  normal  one  CPU  system,  the  CPU  always  has  its  request  on  and 
the  DMA  can  always  come  and  steal  the  bus  anytime  DMA  is  enabled  and  the  bus  is 
not  locked  and  not  busy.  It  provides  a  bus  grant  to  the  CPU  which  is  sampled 
synchronously  at  20  MHz  clock.  The  bus  arbitor  itself  must  be  synchronous  in 
order  to  ensure  that  the  setup  and  hold  times  for  the  CPU  grant  are  observed. 

Now  in  order  to  synthesize  the  strobe  address  for  the  DMA  functions  (the 
plus  after  the  name  indicating  a  resynchronized  signal  by  the  bus  arbitor) ,  the 
bus  arbitor  uses  the  ready  address  which  is  being  generated  jointly  by  the  MMU 
and  the  BPR.  When  the  bus  goes  ready,  the  bus  arbitor  will  synthesize  bus  ready 
DMA  acknowledge  goes  to  the  BPR  so  that  it  will  know  which  memory  map  to  use  for 
write  protection.  On  this  side  we  have  the  generalized  memory  interface  form  of 
the  signals. 

CHART  028 

Ok,  this  is  a  method  of  control  synchronization  which  was  discussed  with 
Fairchild  two  weeks  ago,  which  uses  the  CPU  clock  and  the  ready  address  coming 
from  the  BPR  and/or  the  MMU.  Suffice  it  to  say  that  when  the  bus  is  not  busy, 
the  strobe  address  flip-flop  is  preset  (active  high) .  When  ready  address  comes 
along,  it  is  sampled  low  at  the  end  of  the  bus  cycle  of  the  CPU  or  the  DMA 
device.  The  bus  goes  not  busy  and  resets  the  resynchronized  strobe  address.  In 
order  to  combine  the  CPU  busy  with  the  DMA  busy,  you  may  have  to  use  an  open 
collector  buffer,  or  a  tri-state  buffer  if  this  line  has  to  go  any  significant 
distance  in  your  system. 

CHART  #29 

This  is  the  simplified  bus  control  part  of  the  generalized  bus  arbitor. 

It  uses  the  two  external  gates  and  a  single  flip-flop  to  give  the  CPU  grant  and 
the  DMA  grant  to  the  subsystems. 
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CHART  #30 

Ok,  this  is  what  it  all  looks  like  when  it  is  pulled  together.  The  ready 
address,  being  open  collector,  is  pulled  up  by  a  IK  resistor.  The  Memory/not 
10  and  the  Data/not  Instruction  status  lines  are  such  that  thev  mav  be  left  in 
the  high  state  or  floating  and  pulled  up  by  IK  resistors  when  DMA  is  going  on. 
These  signals  including  the  strobe  address  re synchronized  go  to  the  MMU  and  BPR. 
The  other  part  of  the  DMA  interface  is  on  the  lower  nart  of  the  diagram. 

CHART  #31 

We'll  talk  about  the  Memory /I0  bus  interface  as  it  leaves  the  chip  set. 
CHART  #32 

The  three  status  signals  that  tell  you  what  is  going  on  are  Memory /not  10, 
Read/not  Write,  and  Data/not  Instruction.  They  were  chosen  so  that  you  would 
be  able  to  pull  these  lines  to  the  default  (high)  state  meaning  Memory  and  Data 
(not  Instruction)  when  DMA  is  going  on.  A  very  straightforward  encoding  of  the 
status  lines  down  to  the  point  where  we  get  to  the  XIOs.  Now  XIOs  are  divided 
into  two  groups:  those  which  are  implemented  inside  of  the  CPU  and  those  which 
are  implemented  within  the  host  system.  For  those  that  are  inside  of  the  CPU, 
as  part  of  16ZE181  (the  microprocessor  specification)  we  said  we  want  to  be 
able  to  monitor  those  things  as  they  are  being  loaded  or  read  by  the  CPU.  We 
want  to  do  that  for  our  software  test  stations  and  also  for  the  capability  to 
diagnose  faults  within  the  CPU.  Consequently  when  we  read  or  write  anything 
internal  to  the  CPU,  the  CPU  acts  like  it's  a  "write"  to  the  external  equipment, 
except  that  read  data  is  not  sampled.  For  example,  if  it's  reading  Timer  A, 
the  CPU  will  do  an  XIO  type  bus  cycle  with  "write"  status  and  it  will  send  the 
contents  of  Timer  A  out  over  the  bus  at  the  same  time  it  is  being  copied  into 
the  register  file.  The  external  read/write  XIO  cycles  behave  normally.  The 
DMA  read/writes  show  that  the  two  status  lines  can  be  pulled  high. 

CHART  £ 33 

Ok,  Shai  told  you  that  you  can  hold  up  the  address  portion  of  the  transfer 
cycle  by  withholding  the  ready  address. 

CHART  #34 

.The  design  goals  for  the  setup  and  hold  of  ready  address  are  30  nanoseconds. 
Status  becomes  valid  30  nanoseconds  after  the  beginning  of  the  cycle  as  the  bus 
goes  busy.  The  MMU  uses  the  status  along  with  address  information  to  access  the 
instruction  registers  or  data  registers  to  perform  the  memory  protection 
algorithm  required  by  1750  and  eventually  gets  a  mapped  memory  physical  address 
out  here.  We  would  not  expect  that  the  host  system  would  use  the  ready  address. 
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CHART  #35 


This  is  the  way  it  all  fits  together  with  the  bus  arbitor,  the  ready  address 
and  resynchronized  address  strobe  being  drawn  in  explicitly.  The  BPR  and  MMU 
cooperatively  pull  down  on  the  ready  address  meaning  "not  ready"  at  the  beginning 
of  the  data  transfer  angle.  Once  the  MMU  determines  the  extended  memory  address 
is  valid,  then  it  tells  the  BPR  to  lock  in  its  map.  The  BPR,  once  it  determines 
the  write  protect  status,  releases  its  ready  address.  The  bus  arbitor  in  turn 
generates  the  resynchronized  address  strobe  to  the  MMU  and/or  the  BPR.  It  uses 
the  bus  busy  to  do  that  and  therefore  does  not  require  any  use  of  the  CPU  busy 
or  address  strobe. 

CHART  #36 


This  is  the  timing  diagram  for  the  read  bus  cycle.  On  a  read  cycle  the 
address  for  the  memory  (or  XIO  command)  comes  out  first.  As  the  address  strobe 
drops,  the  address  is  latched  by  the  host  subsystem.  The  bus  must  then  be  turned 
around  and  the  external  bus  must  be  gated  into  the  CPU.  Now  Fairchild  has  designed 
their  chip  so  that  the  data  strobe  will  not  start  before  the  internal  bus  has  gone 
tri-state  so  there  should  be  no  bus  contention  right  here.  The  read  data  comes 
on  to  the  bus  and  requires  a  setup  time  of  10  nanoseconds  setup  time  with  respect 
to  the  CPU  clock. 

CHART  #39 


But  there  is  a  warning.  If  you  turn  around  the  bus  to  read  data,  you  must 
turn  it  around  again  to  get  the  next  address  out.  From  the  time  strobe  data 
goes  away,  if  you  are  using  strobe  data  to  control  your  bus  buffers,  you  have  45 
nanoseconds  to  get  your  bus  buffer  tri-stated  before  the  CPU  begins  to  send  the 
next  address. 

CHART  #40 


Ok,  where  do  you  get  all  your  address  lines  for  the  system?  XIO  commands  are 
easiest  since  they  always  come  from  the  16  address  bits  multiplexed  out  at  the 
beginning  of  the  cycle.  Memory  address  lines  (most  significant  bits)  must  be 
taken  from  the  memory  management  unit  (if  present)  and  the  12  least  significant 
bits  come  from  the  multiplexed  address/data  bus.  Address  errors  are  decoded  in 
the  host  subsystem  and  reported  to  the  CPU  by  the  illegal  address  discrete  where 
it  sets  the  bits  in  the  fault  register. 

CHART  #41 

• 

This  is  a  block  diagram  of  a  non-multiplexed  CPU  card  with  a  generalized  bus 
arbitor  illustrating  a  serial  DMA  device  bus  acquisition  scheme.  The  memory/10 
bus  is  on  the  left.  There  is  only  one  gate  delay  between  the  transmit/not  receive 
input  and  strobe  data  to  prevent  bus  contention  at  the  end  of  the  bus  cycle.  The 
373  latches  demultiplex  the  address  lines  for  the  memory/IO  subsystem. 
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CHART  #41  (CONT'D) 

Now  for  DMA  to  get  in  and  access  the  memory  protect  maps  in  the  memory  manage¬ 
ment  unit  and  the  block-protect  RAM,  it  must  gate  its  address  onto  the  internal 
bus.  That's  the  only  way  the  MMU  and  BPR  can  get  this  information.  This  is  done 
via  the  address  buffers  shown  in  the  lower  part  of  the  diagram.  The  bus  arbitor 
will  synthesize  an  address  strobe  for  the  MMU  and  BPR  using  the  CPU  clock  for  the 
DMA  access  cycle. 

The  read/write  line  is  shown  as  being  bi-directional .  When  the  CPU  is  in 
control,  the  line  is  driving  out  and  when  the  DMA  is  in  control,  the  line  is 
driving  onto  the  internal  bus.  The  Memory/not  10  and  Data/not  Instruction  status 
lines  are  simply  pulled  up  at  the  host  subsystem  interface. 

CHART  H2 

Ok,  this  set  of  notes  is  about  memory  system  design — access/cycle  times  or 
"what  do  1  have  to  do  to  make  the  CPU  run  without  wait  states?" 

CHART  /M3 

First  the  CPU  alone.  If  we  cut  off  the  processor  bus  at  its  pins,  not  taking 
into  account  any  external  data  buffers  that  are  required  to  interface  with  memory, 
then  we  can  talk  about  access  times  with  respect  to  a  memory  system  which  is 
everything  outside  of  the  chip  set.  Basically  the  processor  gets  the  address  out 
and  valid  AO  nanoseconds  after  the  beginning  of  the  SI  and  it  required  data  10 
nanoseconds  before  the  end  of  S3.  Using  that,  you  can  write  the  equations  for 
the  access  and  cycle  times  where  N  is  the  number  of  wait  states  and  f  is  the 
frequency  in  megahertz. 

You  have  a  minimum  of  three  states  plus  the  number  of  wait  states  minus  30 

nanoseconds.  That  is  summarized  in  a  table  on  a  following  chart.  The  cycle  time 

for  an  external  memory  reference  without  wait  states  is  four  states  minimum  plus 
the  number  of  wait  states. 

CHART  #44 

Now  when  you  have  an  MMU,  the  MMU  inserts  a  minimum  of  two  wait  states  in 
any  memory  access  time.  As  Shai  pointed  out,  if  you  get  a  miss  on  the  instruc¬ 
tion  address  or  operand  address,  then  it  adds  another  two  wait  states.  For  the 

MMU  Chen,  the  minimum  access  time  becomes  five  states  plus  a  factor  which  is 
expressed  here  us  a  Boolean  vairable  whose  value  is  two  if  a  page  boundary  is 
cross  on  zero  otherwise.  * 
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CHART  #44  (CONT'D) 

Because  Che  MMU  is  using  Che  scacus  informacion  generaced  by  Che  processor, 
ic  caxwoc  begin  Co  enable  ics  exCended  address  bus  uncil  Chac  gees  sCable. 

Beyond  chac  ic  cakes  an  addicional  50  nanoseconds  Co  gee  Che  exCended  address 
bus  scable  ouc  here.  So  if  you're  councing  from  Che  beginning  of  Che  firsc  SI, 
ic  Cakes  90  nanoseconds  Co  gee  che  exCended  address  bus  valid,  vlch  Che  same 
requiremene  of  geccing  data  valid  10  nanoseconds  before  che  end  of  S3. 

CHART  #45 

This  chare  gives  che  access/cycle  eimes  co  operate  with  a  fixed  number  of 
wait  states  for  three  CFU  clock  frequencies.  Ac  20  megahertz  in  order  Co  operate 
with  no  wait  states  requires  a  100  nanosecond  system  memory  access  time.  Nov 
system  memory  includes  everything  from  Che  CPU  data  buffers  through  che  address 
latches,  Che  address  decoders,  che  access  time  in  Che  memory  and  through  its 
buffers  (if  any) .  One  wait  state  will  get  you  130  nanoseconds  access  time  while 
four  wait  states  vill  get  you  300  nanoseconds.  Now  with  an  MMU,  assuming  no  page 
boundaries  are  crossed,  che  access  Cime  extends  Co  15Q  nanoseconds  with  a  300 
nanosecond  cycle  cime. 

This  chart  includes  all  delays  in  Che  memory  system  outside  of  che  processor. 

V)  You  can  see  that  it  is  a  very  tight  memory  system  which  is  required. 

CHART  #46 

Another  point  about  che  memory  system  is  Chat  Che  CPU  discovers  Coo  late 
in  its  data  transfer  cycle  that  the  memory  should  be  write  protected.  It  goes 
ahead  and  generates  a  data  strobe  and  relies  on  the  memory  system  to  use  the 
memory  protect  error  being  generated  by  the  MMU  or  Block-Protect  RAM  to  pass  or 
not  pass  the  data  strobe  along  to  the  final  memory  element.  One  additional  note 
is  that  with  no  wait  states,  the  data  strobe  is  specified  to  be  43  nanoseconds 
minimum  in  duration.  Also  the  data  strobe  is  well  centered  in  the  middle  of  the 
memory  protect  error  signal  so  that  simple  gating  can  take  care  of  that. 

CHART  049 

Memory  error  control  is  all  done  all  by  the  memory  system  external  to  the 
chip  set.  It  is  all  reported  to  the  CPU  by  a  single  memory  parity  error  discrete 
which  sets  bits  in  the  fault  register.  The  line  is  sampled  at  the  conclusion 
of  each  memory  cycle  on  the  trailing  edge  of  the  bus  busy.  If  it  is  low  at  that 
time,  then  bit  2  of  the  fault  register  is  set  which  triggers  s  machine  error 
Interrupt  (if  not  masked).  You  can  implement  any  memory  error  detection  scheme 
you  want,  e.g..  Byte  Parity,  Word  Parity,  Hamming  Codes.  However,  all  those 
error  signals  must  get  down  to  one  line  for  fault  reporting  to  the  CPU. 
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CHART  if 50 

The  memory  fault  status  register  is  an  option  in  1750  which  is  not  imple¬ 
mented  within  the  chip  set  but  is  easy  to  do  if  needed.  The  AF  control  board 
met  and  decided  that  the  memory  fault  status  register  should  be  loaded  on 
illegal  address  errors,  parity  errors,  and  memory  protect  errors.  All  these 
errors  'OR'  down  conceptually  to  a  single  clock  line  to  a  register.  The  con¬ 
tents  of  the  register  are  shown  at  the  bottom  of  the  chart.  The  four  address 
state  bits  of  the  processor,  the  memory/not  10  status  line  (inverted)  and  the 
four  most  significant  bits  of  the  page  address  on  the  memory  address  bus. 

CHART  £ 51 

The  start-up  ROM  is  a  feature  that  is  very  easy  to  implement  via  XIO  commands. 
You  decode  the  start-up  ROM  enable  and  disable  commands  and  use  a  cross-coupled 
latch  flip-flop  cleared  by  reset  so  that  is  always  enabled  at  power  on  in 
accordance  with  the  standard. 

CHART  #52 

A  few  more  notes  about  10  system  design  are  included  here. 

CHART  it  5  3 

An  example  of  an  10  word  that  will  be  in  every  microprocessor  system  designed 
with  this  chip  set  is  the  configuration  word.  The  configuration  word  tells  the 
CPU  whether  the  MMU,  the  BPR,  the  user  console  and/or  a  co-processor  are  present. 

It  must  be  there.  The  configuration  word  is  assigned  to  XIO  command  8410. 

CHART  #54 

On  the  F-16  we  use  the  following  XIO  command  spaces.  A  lot  of  commands  in 
the  1750  specification  are  in  the  range  of  2000-200F,  etc.  The  Block  Protect 
RAM  uses  256  locations.  The  avionics  1553  multiplex  data  bus  is  allocated  512 
locations,  and  the  chip  set  reserves  4  locations. 

CHART  //55 

In  summary,  we  believe  that  we  are  compatible  with  all  the  issues  resolved 
by  the  1750A  control  board  on  20  July  1981.  We've  met  all  our  F-16  requirements 
described  in  16PP379A,  dated  7  July  1981.  And  we  think  we  have  a  good  technical 
solution  to  providing  a  microprocessor  chip  set  for  general  application. 
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GENERALIZED  BUS  ARBITER 
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SUMMARY 
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TEXT  FROM  THE  THIRD  TECHNICAL  FORUM,  5  MAY  1982 


CHART  #1 


We  are  going  to  examine  the  evaluation  units  that  Fairchild 
will  provide  to  General  Dynamics  under  the  mi croprocessor 
development  contract.  The  units  will  be  used  to  test  the  chip 
set,  and  evaluate  it's  potential  for  integration  into  the  core 
avionics  aplications. 


CHART  #2 


The  test  equipment  will  support  these  four  tasks,  and  possibly 
a  few  more.  It  will  support  the  console  control  that  Shai 
discussed  earlier.  For  instance,  reading  and  writing  to  memory, 
reading  and  writing  to  the  internal  registers  and  the  ability  to 
run  and  halt  the  processor.  The  equipment  will  also  be  used  to 
support  SEAFAC  validation,  which  I  will  describe  in  a  little  more 
detail.  Validation  will  be  accomplished  by  hosting  the  SEAFAC 
test  load  modules  on  a  mainframe  computer,  and  then  downloading 
them  to  the  FSl  discs.  The  load  modules  will  then  be  run  on  the 
chip  set  one  at  a  time  to  obtain  the  test  results,  and  finally 
validate  the  mi croprocessor .  I  should  mention  that  complying  with 
the  SEAFAC  ATP  is  a  part  of  our  specification  requirements.  The 
FSl  will  also  be  used  to  perform  other  testing  under  chip  set 
contract — namely  acceptance  testing  and  qualification  testing. 


CHART  #3 


Fairchild  will  provide  to  Honeywell  Avionics  of  Minneapolis, 
one  of  their  subcontractors,  a  standard  FSl  Fairchild  System  One 
which  is  a  commercial  minicomputer.  It  has  a  9445  bit  slice 
emulator,  64K  of  memory,  two  floppy  disk  drives,  and  an  integrated 
CRT  keyboard  unit.  It  will  be  provided  to  General  Dynamics  with 
disk  operating  system  software  and  other  support  software 
packages.  There  are  several  I/O  ports  for  a  link  to  a  mainframe, 
to  a  printer  and  to  the  CRT  keyboard. 


CHART  #4 


Honeywell  will  design  and  build  a  test  card  that  will  plug  into 
the  motherboard  of  the  FSl.  This  card  will  contain  a  bus 
interface  to  the  FSl  Nova  bus,  and  an  interface  *o  the  chip  set 
information  bus,  which  contains  the  handshaking  and  protocol 


D.  M.  SDQTT 
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signals.  The  card  will  contain  sons  zero  insertion  -force  sockets, 
so  we  can  easily  test  various  chip  sets.  There  will  be  jumper 
headers  that  we  can  use  to  bypass  the  MMU  and  EF'R  to  allow  testing 
any  of  the  -four  con-f  i  gui  rati  ons.  The  test  card  will  also  have  64K 
words  o-f  16  bit  memory,  and  the  console  inter-face  I  talked  o-f 
earlier.  The  card  will  allow  us  to  simulate  the  external 
processor  I/O,  such  as  DMA  simulation,  interrupt  simulation  and 
things  of  that  nature.  There  will  be  test  points  for  logic 
analyzers  and  scopes  to  aid  in  debugging  any  problems  with  the 
chip  set. 


CHART  #5 


Randal  mentioned  earlier  that  we  are  still  defining  the 
requirements  for  this  piece  of  equipment.  We  haven’t  conducted  a 
formal  design  review  on  the  equipment  so  it  is  not  in  it’s  final 
form  at  this  time.  On  the  card  that  Honeywell  is  building  will  be 
a  hardware  control  panel  that  will  be  used  with  the  early  runs  of 
silicon,  which  might  not  be  fully  functional.  The  control  panel 
will  allow  us  to  run  and  halt  the  processor  and  to  single  step 
through  instructions,  and  if  necessary  individual  clock  cycles. 

The  address/data  bus  will  be  displayed  so  that  we  can  see  what’s 
happening  in  the  CPU  as  it  communicates  with  the  other  devices  and 
with  memory.  There  will  be  hardware  breakpoint  capability,  which 
is  still  be  formulated  because  of  the  pipelined  archi tecture. 

There  will  not  be  any  interrupt  or  DMA  simulation,  because  on  the 
eary  parts  we  will  be  concentrating  on  the  internal  workings  of 
the  chip  set. 
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o  BASIC  MNEMONICS  ARE  MODIFIED  BY  SUFFIXES  TO 
SPECIFY  OPERAND  TYPE,  SHIFT  DIRECTION,  ETC. 
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SUFFIXES  ARE  ALSO  APPLIED  TO  THE  BASIC  BRANCH 
MNEMONIC  "B"  TO  SPECIFY  CONDITIONAL  BRANCHING 


01 

01 

■3 

N 

01  r-t 

X 

co  (0 

Vi 

o 

3  C 

o 

o 

C 

0 

u 

co 

0)  *H 

01 

u 

43  U 

O 

r-1 

> 

x 

•H 

u 

CO 

1-1 

>4  3 

3 

4-1 

H 

2  C 

r-l 

cr 

CO 

<0 

a  o 

cO 

01 

00 

c 

w  O 

3 

01 

o 

o* 

Vi 

c 

u  u 

01 

O 

s-< 

4-1 

0)  01 

1-1 

O)  X 

>1 

o 

c 

c 

01 

X) 

u 

o 

u 

cO 

CO 

> 

c 

00  o 

X 

X 

•H 

o 

«0 

c 

c 

r-4 

u 

4-1 

U 

o 

I— •  >4 

c0 

O 

CO 

01 

•H 

c 

hi  C 

X 

X 

4-1 

3 

Vi 

Vi 

> 

CO 

3 

<0 

*J 

w 

cr 

01 

01 

•H 

O 

>4 

r— 1 

01 

•u 

1-1 

U 

o. 

li 

n  x 

CO 

(0 

CO 

CO 

cO 

CO 

co 

cd 

o 

oi 

Vl  w 

01 

co 

CO 

3 

u 

01 

01 

01 

t>0 

1-1 

u 

<0  -rl 

X 

01 

01 

O* 

o 

Vi 

Vi 

X 

01 

o 

01 

m 

O  5 

•rl 

X 

rJ 

W 

z 

o 

o 

1-1 

z 

z 

04 

OtS  o 


W  W  W  H 

►4  W  Z  U  O 


Pj  N  Z 

Z  Z  04  Z  Z  PU 


Not  zero 

Not  negative  (positive  or 
Positive 


APPLYING  THESE  RULES  TO  MI L-STD-1750A  ADD 
INSTRUCTIONS  YIELDS: 


M  MNEMONICS  COMPRESSED  INTO  A  ALL  EASILY  RECOGNIZABLE 
AS  ADD  INSTRUCTIONS 


ADDRESSING  MODES  ARE  REMOVED  FROM  THE  MNEMONIC  AND 
PLACED  IN  THE  OPERAND  FIELD 
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DATA  STORAGE  DIRECTIVE  FOLLOWS  GENERAL  IEEE 
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Margin  Comments 


R.  BYRNE 

TEXT  FROM  THE  THIRD  TECHNICAL  FORUM,  5  MAY  1982 
CHART 


We  are  very  briefly  going  to  discuss  and  look  ahead  to  the  ultimate  availability 
of  the  chip  set,  and  we  are  going  to  discuss  a  little  bit  about  how  it  will  be  avail¬ 
able,  and  where  it  will  be  manufactured  and  those  issues.  We  are  also  going  to  very 
briefly  talk  about  long-term  support  to  users  of  the  chip  set  that  will  be  available. 

CHART  #2 


First  thing  I  want  to  cover  here  is  production  facilities,  JAN  qualification, 
estimate  of  delivery  availabilities,  rough  order  of  magnitude  estimate  of  cost, 
and  something  we  call  a  demand  entry  system,  which  is  an  early  way  of  getting  on 
the  list.  And  then  later  on  we  will  talk  a  little  bit  about  our  user  support  system. 

CHART  '#3 


I  put  this  foil  of  Shai's  back  up  here  in  case  there  exists  any  confusion  as 
to  what  is  meant  by  the  term  "chip  set".  The  chip  set,  as  you  know  from  earlier 
discussion,  consists  of  really  four  elements;  the  CPU,  the  block  protect  RAM,  the 
MMU,  the  93479  RAMs  and  the  54F273  buffers.  Our  discussion  will  involve  all  of 
these  parts,  so  it  should  be  recognized  that  the  buffers  and  RAMs  are  standard  de¬ 
vices  that  are  part  of  Fairchild's  standard  product  line. 

CHART  #4 


Initially  the  9450,  which  is  a  CPU,  as  well  as  the  9451  and  52  will  be  coming 
out  of  our  facility  in  Palo  Alto,  California,  and  later  from  Wappinger  Falls,  New 
York.  The  long-term  production  facility  will  be  Wappinger  Falls,  New  York.  The 
93479,  which  is  the  256  x  9  RAM  will  be  coming  out  of  Mountain  View,  in  San  Jose 
and  later  Puyallup,  Washington,  and  the  54F245  buffer  will  always  come  out  of  South 
Portland,  Maine. 

CHART  it  5 


What  we  are  looking  for  on  this  chip  set  is  satisfying  all  the  requirements 
for  a  military-grade  integrated  circuit.  We  will  meet  and  satisfy  the  MIL-M-38510 
Rev.  E  requirements.  And  we  will  quality  our  facilities  to  38510  as  well  as  883  as 
well  as  MIL-STD-976. 

In  the  area  of  device  specifications,  or  slash  sheets,  we  have  a  requirement 
as  part  of  the  contract  to  deliver  a  draft  of  a  slash  sheet  for  the  50,  51,  and  52. 
The  slash  sheets,  that  is  the  JAN  slash  sheets,  for  the  245  should  be  released 
through  RADC  and  DESC  in  1983  and  the  93479  slash  sheet  is  an  area  of  discussion 
between  the  program  team  and  the  DESC  people  at  this  point  in  time.  That  product 
is  similar  to  a  slash  233,  which  is  a  4K  bipolar  RAM  which  is  already  in  the  JAN 
system.  Estimate  time  for  JAN  qualifications  Class  B  -  second  half  of  1985;  Class 
S  -  probably  second  half  of  1986. 
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CHART  if  6 

JAN  qualifications  are  way  out,  by  the  nature  of  the  system,  so  we  will  be 
looking  for  a  DESC  item  drawing  to  become  a  standard  procurement  document.  The 
release  of  that  will  be  triggered  by  the  delivery  of  the  100  preproduction  units 
to  GD.  All  procurement  actions  are  triggered  by  that  delivery.  Meantime,  there 
will  be  Fairchild  preliminary  information  sheet,  and  advanced  data  sheet,  out  in 
September  1982. 

CHART  #7 

Estimate  of  availabilities  are  based  on  delivery  of  100  preproduction  units 
to  GD.  Shipment  to  GD/Fort  Worth  -  September  of  1983.  We  are  allowing  a  couple 
of  months  in  there  for  a  GD/FW  approval  cycle.  It  may  go  faster  than  that  and 
shipments  could  then  start  to  others  roughly  two  months  after  approval  by  GD  or 
January  1984.  An  estimate  on  volume  -  the  ramping  up  of  volume  will  start  in  the 
first  quarter  of  1984,  roughly  100  units  per  month  to  500  units  per  month  in  the 
second  half  of  1984,  and  a  demand  level  of  production  by  the  first  quarter  of  1985. 
By  demand  level  I  mean  we  will  scale  the  production  to  the  demand  that  is  coming  in. 
Now  ROM  by  the  way  in  this  presentation  stands  for  "Rough  Order  of  Magnitude"  not 
Read  Only  Memory. 

CHART  //  8 

Current  Rough  Order  of  Magnitude  estimates  of  cost  -  $650  for  the  CPU,  roughly 
$100  each  for  the  block  protect  RAM  and  the  MMU,  $12  for  the  buffer  and  $30  for  the 
RAM.  These  are  -55  to  +125°C  parts.  Firm  prices  again  will  be  available  not  later 
than  the  shipment  to  General  Dynamics  of  the  first  100  units,  and  tied  to  the  re¬ 
lease  of  a  DESC-selected  item  drawing.  We  would  like  to  get  to  one  source  control 
drawing,  not  get  a  source  control  drawing  in  from  every  possible  user. 

CHART  //9 

All  the  normal  procurement  requirements  will  be  complied  with,  and  these  are 
1981  dollars  for  1984  delivery.  Now  this  is  in  lieu  of  a  formal  order  entry  system. 
We  have  a  number  of  requests  from  people  who  would  want  to  enter  orders,  and  the 
actual  creation  of  a  formal  contract  is  a  little  premature  at  this  point  in  time. 

So  we  have  created  something  we'll  call  a  "demand  entry  system".  We  are  asking  for 
a  letter  from  your  procurement  authority,  and  the  reason  for  that  is  so  that  out 
of  one  company,  we  end  up  getting  one  letter  for  one  requirement,  and  not  ten 
letters  from  ten  different  levels  of  the  same  company  for  the  same  requirements. 

Who  you  are,  what's  the  quantity  requirement,  what's  the  schedule  requirement,  pro¬ 
gram  identification,  contact  point,  things  like  that. 

Priority  ratings  are  quite  important  in  this  case.  We  will  respond  to  that, 
and  we  will  acknowledge  it.  Acknowledgment  will  essentially  say  we  received  the 
letter  and  we  have  scheduled  and  logged  the  requirements,  and  you  will  be  provided 
a  periodic  update  on  the  availability  and  schedule  situation. 
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CHART  #10 

As  to  mailing  address,  there  are  three  things  of  importance: 

1.  Copies  of  your  requirement  letter  as  well  as  our  logs  are  available  to  the 
government. 

2.  Please,  no  classified  information. 

3.  Please,  no  business  sensitive  information  within  the  meaning  of  the  freedom 
of  information  act. 

CHART  #11 

Now  briefly,  what  we've  talked  about  so  far  in  this  presentation  is  when  parts 
will  be  available  and  roughly  what  they  will  cost.  The  second  portion  of  this  pre¬ 
sentation  is  going  to  deal  with  some  preliminary  information  on  our  plans  for  pro¬ 
viding  some  support  to  the  users  of  the  chip  set  beyond  that  which  might  be  available 
as  a  result  of  the  effort  that  is  being  undertaken  by  GD,  but  consistent  with,  and 
in  consort  with,  that  work. 

CHART  #12 

We  want  to  or  will  work  within  the  framework  of  utilizing  the  tools  that  were 
just  discussed  in  the  presentation  here  just  a  few  minutes  ago.  Secondly,  we  look 
at  the  potential  of  providing  a  local  in-circuit  emulation  and  debugging  support 
utilizing  our  existing  Fiarchild  FS1  system  as  well  as  our  existing  EMUTRAC  system. 

CHART  //13 

Briefly,  EMUTRAC  is  an  in-circuit  emulation  and  tracing  system.  We  call  it 
"Emulation  and  Tracing".  It  is  used  to  support  our  existing  line  of  microprocessors. 
It  is  coming  on  and  we  look  forward  to  supporting  at  least  a  portion  of  the  9450 
with  this' system. 

CHART  //14 

Just  a  very  brief  picture  of  a  set-up.  The  EMUTRAC  system  currently  resides 
in  the  FS1  chassis.  It  has  a  module  or  board  which  targets  the  EMUTRAC  to  the 
processor  that  is  b<  ..ng  used.  The  rest  of  this  is  pretty  basic;  there  are  files, 
printers,  terminals,  those  kind  of  things. 

CHART  #15 

We  have  in  place  microprocessor  resource  centers,  which  are  application  engi¬ 
neering  centers.  They  are  located  currently  at  these  locations  both  in  the  U.S. 
and  in  Europe.  We  plan  to  bring  one  aboard  in  Dayton  as  this  program  matures. 

And  our  staff  in  these  programs,  in  these  centers,  will  be  trained  to  provide  user 
level  application  support  on  the  MIL-STD-1750  chip  set. 
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CHART  $15  (Cont’d) 

One  last  thing,  we  will  provide  the  normal  reliability  and  QA  support  that 
you  people  require,  utilizing  this  type  of  device  in  a  high-performance,  high- 
reliability  application.  We  will  provide  continual  life  testing.  We  will  meet 
and  continue  to  meet  the  MIL-STD-883B,  MIL-M-38510  requirements  as  they  are 
modified,  interpreted  and  published  by  DESC  and  RADC.  And  we  will  support  appro 
priate  government  source  inspection  requirements. 
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MICROPROCESSOR  LIFE  CYCLE  COSTING  FOR  MIL-STD  1750A 


Janice  L.  Lyons 
General  Dynamics 


The  U.S.  Air  Force  is  interested  in  installing  a  standard 
microprocessor,  as  soon  as  possible,  in  current  and  next  gene¬ 
ration  fighter/attack  aircraft  and  other  defense  systems.  A 
standard  microprocessor  would  eliminate  the  need  for  maintain¬ 
ing  multiple  software  packages  and  multiple  chips  and  chip  sets. 

This  paper  presents  an  approach  for  analyzing  the  life 
cycle  costs  of  such  a  standard  microprocessor,  specifically  that 
defined  in  MIL-STD-1750A.  The  costing  approach  was  formulated 
to  highlight  the  operational  and  design  differences  found  be¬ 
tween  military  standard  and  conventional  commercial  micro¬ 
processors  as  employed  in  a  military  environment.  Both  hard¬ 
ware  and  software  life  cycle  cost  implications  are  addressed. 


INTRODUCTION 


The  MIL-STD-1750A  microprocessor  specification  presents  a 
revolutionary  concept  for  microprocessor  design.  The  standard 
does  not  specify  a  specific  hardware  configuration,  but  rather 
defines  a  standard  for  processing  functions  and  chip  perfor¬ 
mance.  That  is,  the  microprocessor  can  be  designed  as  either  a 
a  highly  integrated  chip  or  as  a  chip  set.  This  approach 
allows  the  microprocessor  instruction  set  and  software  to  re¬ 
main  constant  as  the  hardware  incorporates  technology  advances. 
The  chip/chip  set  can  then  evolve  to  remain  responsive  to 
changing  user  needs. 

Such  an  innovative  approach  to  chip  design  and  standardi¬ 
zation  presents  a  problem  in  assessing  the  impact  on  life  cycle 
cost.  At  present,  there  is  very  little  cost  data  and  related 
information  on  microprocessors,  much  less  the  information  re¬ 
quired  to  project  the  cost  of  a  design  such  as  1750A.  This 
paper  does  not  attempt  to  address  the  specific  costs  of  the 
standard  microprocessor;  instead  the  sections  that  follow 
present  the  approach,  assumptions  and  methodology  used  to 
analyze  MIL-STD-1750A  life  cycle  costs. 

AREAS  OF  CONSIDERATION 

In  studying  the  1750A  microprocessor  costs,  it  was  dis¬ 
covered  that  the  differences  between  a  military  standard  pro¬ 
cessor  and  a  conventional  commercial  processor  were  most 
apparent  in  the  operations  and  support  phase  of  the  life  cycle. 
These  O&S  differences  can  be  attributed  to  such  design-related 
characteristics  as  the  MIL-standard  processor  being  an  instruc¬ 
tion/operating  standard  as  opposed  to  a  hardware  standard, 
as  well  as  a  general  design  capable  of  effective  operation  in 
more  than  one  type  of  operating  environment. 

As  a  microprocessor  operating  standard,  the  1750A  processor 
has  a  standard  instruction  set  which  impacts  both  hardware  and 
software  revisions  and  maintenance.  A  standard  higher  order 
language  (HOL)  becomes  feasible  as  the  programming  language 
is  no  longer  dictated  by  the  compiler  within  the  individual 
microprocessor.  The  processor  software,  developed  to  be  com¬ 
patible  with  the  instruction  set,  becomes  independent  of  system 
hardware  changes  and  modifications.  As  technology  advances  and 
new  microprocessor  chips  and  chip  sets  are  brought  into  service, 
minimal  software  changes  are  required  to  successfully  integrate 
the  revised  hardware  into  the  operating  system.  Also,  no 
massive  software  upgrades  are  needed  to  match  hardware  technol¬ 
ogy  advances;  software  revisions  should  be  minimal  and  should 
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occur  on  a  continuing  basis. 

With  changes  in  chip  technology  transparent  to  the  soft¬ 
ware,  hardware  revisions  can  occur  as  justified  to  meet  changing 
user  needs.  This  allows  the  microprocessor  system  to  realize 
the  benefits  from  continuing  improvements  in  such  areas  as  reli¬ 
ability,  which  has  historically  improved  14%  annually.2 

The  compatibility  of  the  1750A  microprocessor  with  mul¬ 
tiple  operating  environments  encourages  its  wide-spread  appli¬ 
cation  in  military  weapon  systems.  By  not  being  weapon  or 
function  specific,  the  microprocessor  may  be  manufactured  in 
significant  quantities  and  thus  realize  cost  reductions  due  to 
economices  of  scale.  Additional  cost  reductions  can  be  realized 
through  competitive  bidding  since  larger  production  quantities 
will  make  multiple  source  contracting  feasible. 

Multiple  weapon  system  usage  will  also  affect  the  quantity 
of  spares  required.  Spares  provisioning  further  impacts  inven¬ 
tory  management  and  technical  data  requirements.  As  micropro¬ 
cessor  maintenance  becomes  less  weapon-specific,  support  equip¬ 
ment  will  also  benefit  from  economies  of  scale  since  universal 
designs  can  be  utilized  as  opposed  to  multiple  specialized  equip¬ 
ment.  Additionally,  support  equipment,  like  the  processor,  will 
benefit  from  being  more  widely  procured  and  operated. 

COSTING  APPROACH 

Microprocessor  life  cycle  costs  (LCC)  were  divided  into 
categories  as  shown  in  Table  1.  These  divisions  of  LCC  by 
hardware  and  software  are  believed  to  best  represent  the  cost 
impacts  of  the  available  performance,  operations  and  support 
information.  In  defining  the  approach  to  costing,  a  ten-year 
life-cycle  was  assumed;  electronics  systems  are  typically  up¬ 
dated  every  five  years, 1  thus  a  ten-year  life  cycle  takes  into 
account  one  complete  hardware/software  revision  of  the  micro¬ 
processor. 

The  hardware  costing  task  was  approached  as  a  standard  pro¬ 
curement  costing  problem.  Estimates  were  received  from  micro¬ 
processor  developers  as  to  the  expected  development  costs  for 
a  military  standard  processor.  A  representative  development 
cost  figure  was  chosen  with  the  help  of  the  Air  Force  to  rep¬ 
resent  the  1750A  chip  development  effort. 3 

A  survey  approach  was  also  taken  to  determine  unit  costs 
for  a  specific  quantity  buy.  The  information  received  indicated 
a  70%  "learning  curve"  effect  as  microprocessor  chip  quantities 


TABLE  1 


ELEMENTS  OF  MICROPROCESSOR  LIFE  CYCLE  COSTS 


HARDWARE  LCC 
Development 
Production 

Operations  &  Support 

Hardware  Upgrades 
Spares  &  Inventory 
Support  Hardware 
Personnel  Requirements 


SOFTWARE  LCC 

Development  &  Acquisition 

Operations  &  Support 

System  Upgrades 
Software  Maintenance 
Support  Maintenance 
Personnel  Requirements 


increase  from  5000  to  500,000  production  units  per  year  (Figure 
l).1  For  a  relatively  small  annual  procurement  of  1000  chips, 
unit  costs  could  be  expected  to  be  in  the  $4000  range,  while  for 
a  multiprogram  procurement  of  5  million  chips  annually,  costs 
are  expected  to  be  less  than  $100  per  unit.  The  large  vari¬ 
ation  in  microporcessor  costs  due  to  changes  in  annual  pro¬ 
duction  rates  reflects  the  relatively  large  fixed  to  variable 
production  and  development  costs  in  the  microprocessor  industry. 
This  further  emphasizes  the  production  economies  of  scale  avail¬ 
able  in  chip  manufacture  for  widely  used  microprocessor  chips. 

Industry  rules-of-thumb  and  insights  obtained  from  related 
study  efforts  were  the  basis  of  hardware  operations  and  support 
costs  estimates. 

Since  system  upgrades  to  hardware  are  continuous  for  the 
1750A,  no  significant  cost  for  hardware  redesign  is  anticipated; 
design  changes  evolve  with  technology  updates. 

The  spares  quantity  required  over  a  ten-year  period  was 
assumed  to  be  equivalent  to  the  initial  purchase  quantity. 1  The 
processor  design,  whether  it  is  an  integrated  chip  or  a  chip  set, 
determines  the  processor’s  requirements  for  inventory  management 
and  technical  data.  Also,  the  number  of  inventory  items  is 
affected  as  a  general  use  microprocessor  replaces  multiple 
specialty  processors. 


Learning  Curve  Effect  for  Microprocessor  Chip  Production 


Annual  Production  Quantity 


Support  hardware  was  costed  at  30%  of  hardware  procurement 
costs.  Additional  charges  for  specific  support  equipment  were 
not  determined  since  essentially  the  same  equipment  is  necessary 
to  support  the  standard  processor  or  a  commercially  available 
equivalent  system. 4 

Personnel  for  1750A  hardware  maintenance  and  support  is 
initially  expected  to  be  equivalent  to  that  required  for  any 
commercial  microprocessor  system.  For  subsequent  programs  using 
the  standard  processor,  less  personnel  training  and  technical 
data  should  be  required  as  a  result  of  parts  standardization. 

The  manpower  requirements  are  not  expected  to  be  altered  signifi¬ 
cantly  since  the  reliability  and  maintainability  of  electronics 
systems  will  not  be  significantly  impacted  by  the  standard  pro¬ 
cessor  . 

Software  development  and  acquisition  costs  were  determined 
by  analogy  with  other  software  efforts.  To  initially  write  code 
for  the  1750A  would  be  equivalent  to  writing  code  for  any  other 
new,  untried  processor. ^  Once  the  code  is  written,  however, 
co=ts  to  upgrade  the  code  to  incorporate  hardware  changes  should 
be  minimal.  Normally,  a  processor  requires  20%  of  its  initial 
code  to  be  upgraded  annually  due  to  hardware  revisions  reflect¬ 
ing  technology  improvements.1  In  the  case  of  the  standard  pro¬ 
cessor,  changes  in  chip  technology  should  be  transparent  with 
respect  to  the  software. 

Software  maintenance  costs  average  90%  of  software  develop¬ 
ment  and  acquisition  expenses.  This  is  typically  27%  of  soft¬ 
ware  life  cycle  costs  where  system  upgrades  are  made  on  an 
annual  basis.  (Table  2.)1 

Support  software  costs  depend  on  the  quantity  of  mainten¬ 
ance  tests  required  to  f ault-isolate  a  chip  set  to  the  desired 
level.  Development  of  maintenance  tests  requires  an  average  of 
six  man-months  per  chip  fault-isolated. 4 

The  impact  of  the  standard  processor  on  software  mainten¬ 
ance  personnel  costs  is  realized  predominantly  in  the  area  of 
training.  With  a  standard  instruction  set,  less  training  is 
required  to  keep  a  programmer  competent  in  compiler  assembler 
language  since  the  language  in  use  is  not  constantly  changing. * 
Other  personnel  cost  savings  are  inherent  in  the  reduction  of 
the  system  upgrading  task. 

CONCLUSION 

The  U.S.  Air  Force  anticipates  significant  long-range 
economic  benefits  to  be  derived  from  the  adoption  of  MIL-STD- 
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TABLE  2 


TYPICAL  SOFTWARE  LCC  BREAKOUT 


FUNCTION 


Development 

Design 

Code 

Test 

Maintenance 

Emergency  Correction 

Routine  Debugging 

Input  Data/Files  Revision 

Updates 

Hardware  Changes 
User  Enhancement 
Documentation  Improvement 
Code  Efficiency  Improvement 
Other 

Life  Cycle  Cost 


%  OF  LCC 


12 

6 

12 


\  30% 


y  . 

6  >  27  & 

12 


4 

30 

4 

3 

2 

100 


'i 

| 

l  43% 


Source:  Ernie  Currey  (Aeronautical  Systems  Division,  Wright- 

Patterson  Air  Force  Base) .  Interview,  4  September  1981 


1750A.  The  most  significant  benefits  are  expected  to  be 
realized  in  the  operations  and  support  phase  of  the  life  cycle 
in  the  areas  of  personnel  training,  hardware  and  software  up¬ 
grades,  and  support  software. 

There  are  also  potential  cost  savings  to  be  gained  from 
large-scale  procurement  of  a  standard  microprocessor.  When 
initially  brought  into  use,  the  1750A  processor  will  be  more 
expensive  than  its  commercial  equivalent  due  to  the  investment 
required  for  research  and  development  and  due  to  its  production 
as  a  specialty  item.  With  widespread  use  of  the  standard,  unit 
costs  are  expected  to  decline  as  yearly  production  quantities 
increase,  and  as  competitors  enter  the  market. 

Whether  the  incorporation  of  a  standard  microprocessor  re¬ 
sults  in  a  cost  savings  or  cost  increase  over  the  life  cycle  is 
determined  by  the  relationship  between  the  initial  investment 
cost  and  the  anticipated  long-term  unit  and  operating  cost 
savings . 
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microprocessor  life  cycle  cost  distribution 

example  of  military  standard  processor 


*  Retirement  Costs  Assumed  Negligible 


STUDY  APPROACH 
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MAJOR  ELEMENTS  OF  LCC  CONSIDERATION 
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HARDWARE  LCC  METHODOLOGY 


RELATED  STUDY  EFFORTS 
INDUSTRY  RULES  OF  THUMB 


PRODUCTION  “LEARNING  CURVE"  EXPERIENCE 

(ECONOMIES  OF  SCALE) 


ANNUAL  PRODUCTION  QUANTITY 


SUMMARY 
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MIL-STD-1750A 


MANAGING  THE  STANDARD 
by  Ronald  S.  Vokits/ASD/AXT 


Abstract 


This  paper  will  cover  the  aspects  of  managing  MIL-STD-1750A  from  the  Control 
Agent's  point  of  view.  The  regulations  governing  this  activity  and  the  respon¬ 
sibilities  of  the  organizations  involved  will  be  discussed. 

Introduction 

MIL-STD-I750A  defines  the  Air  Force's  16  bit  computer  instruction  set  architec¬ 
ture  (ISA).  This  standard  describes  how  the  computer  will  operate  from  the 
assembly  language  programmers'  point  of  view.  It  describes  the  data  formats, 
instruction  operations,  addressing  modes  and  interrupt  operation.  This  standard 
does  not  specify  the  technology,  speed,  or  packaging.  It  defines  an  interface. 

Regulations 

The  application  and  control  of  MIL-STD-1750A  falls  under  three  regulations:  DOD 
5000. 5X,  AFR  800-14,  and  AFR  800-28.  The  Department  of  Defense'  draft  regula¬ 
tion  (DOD  5000. 5X)  provides  guidance  for  standardization  of  ISA's.  Its  primary 
purpose  is  to  reduce  the  life  cycle  cost  of  military  systems  by  reducing  prolif¬ 
eration  of  embedded  computer  systems.  It  requires  that  only  approved  ISA's 
be  used  in  defense  systems  and  subsystems  except  for  three  areas: 

a.  Non-militarized  general  purpose  and  commercial  automatic  data  processing 
computers. 

b.  Automated  test  equipment  and  ground  training  equipment  (simulators). 

c.  Commercial  products. 

The  policy  covers  the  ISA's  approved  for  each  service.  The  Array  will  use 
MIL-STD-1862  (Nebula  ISA)  for  32  bit  computers.  The  Navy  has  three  approved 
ISA's  and  the  Air  Force  has  MIL-STD-1750A.  The  Government  must  have  full  and 
cleariy  defined  rights  to  the  ISA  before  it  can  be  approved  It  is  then  reviewed 
every  two  years.  Each  DOD  component  is  directed  to  set  up  an  office  and  proce¬ 
dures  to  process  waivers  on  the  use  of  standard  ISA's.  AFR  800-14  establishes 
AFSC/XRF  as  the  single  focal  point  for  planning  and  policy  related  to  the  devel¬ 
opment  and  acquisition  of  computer  resources.  AFR  800-28  covers  Air  Force 
policy  on  avionics  acquisition  and  support.  Under  this  regulation,  the  Deputy 
for  Avionics  Control  is  established  as  the  single  Air  Force  organization 
for  focusing  and  controlling  all  Air  Force  avionics  efforts. 
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Control  Process 


The  MIL-STD-1750A  Control  Process  was  established  to  ensure  conformance  with 
DOD  and  Air  Force  policy.  The  control  process: 

a.  Promotes  the  use  of  the  ISA. 

b.  Controls  changes  to  the  standard. 

c.  Provides  a  mechanism  for  making  clarifications  and  inter¬ 
pretations  to  ambiguous  on  conflicting  parts  of  the  standard. 

d.  Establishes  a  means  to  verify  that  a  particular  company 
has  correctly  implemented  the  standard. 

e.  Incorporates  a  means  of  granting  waivers  where  the  use  of 
MIL-STD-1750A  is  not  technically  practical  or  cost  effective. 

The  organizations  involved  and  their  responsibilites  are  as  follows: 

1.  AFSC/XRF  is  the  Designated  Control  Agent  and  must  ensure  that  Air 
Force  policies  are  followed.  The  DCA  controls  all  changes  to  the 
policy  and  reviews  and  approves  all  AFSC  waiver  requests. 

2.  ASD/AXT  is  the  MIL-STD-1750A  Control  Agent.  His  job  is  to  assure 
a  stable  standard.  He  serves  as  Chairman  of  the  Control  Board  and 
establishes  and  maintains  the  Control  Facility.  The  Control  Agent 
is  the  main  interface  between  the  Users  Group  and  the  Air  Force. 

He  does  not  grant  waivers,  but  he  reviews  the  requests  and  makes 
recommendations  to  AFSC/XRF. 

3.  The  Control  Facility  (part  of  the  Systems  Engineering  and  Analysis 
Facility  (SEAFAC)  provides  technical  support  to  the  Control  Agent. 
This  facility  is  manned  by  ASD/ENASF.  Their  job  includes  per¬ 
forming  the  architectual  verification  test,  reviewing  and  eval¬ 
uating  all  changes  recommended  by  the  Users  Group  and 

providing  interpretation  and  clarification  to  the  standard.  Tech¬ 
nical  questions  on  the  standard  and  its  implementation  are  answered 
by  this  group. 

A.  The  Control  Board  consists  of  representatives  from  the  Air  Force's 
user  community.  Its  membership  includes  the  DCA,  CA,  and  the  AFSC 
and  AFLC  organizational  focal  points.  This  group  operates  using 
published  control  procedures.  The  main  function  is  to  review  and 
vote  on  changes  suggested  by  the  Users  Group. 

5.  The  Users  Group  is  composed  of  industry  and  DOD  representatives 

interested  in  promoting  the  use  of  this  standard  ISA.  It  is  an  open 
forum  working  group.  The  DOD  membership  participates  but  does  not 
vote  on  issues. 


THE  CHANGE  PROCESS 


The  change  process  begins  when  a  member  of  the  Users  Group  submits  a  Change 
Proposal  to  the  Chairman  of  the  User  Group.  The  proporsal  is  given  a  number  for 
tracking  purposes,  and  assigned  to  one  of  the  four  committees  (Architecture, 
Standards,  Tools,  and  Verification)  for  review  and  recommendations.  If  the  pro¬ 
posal  is  approved  by  a  two-thirds  majority  of  the  Users  Group,  it  is  sent  to 
the  Control  Board.  The  Control  Facility  evaluates  the  proposed  change  and  pre¬ 
pares  a  report  for  the  Control  Board.  The  Control  Board  reviews  the  change, 
hears  the  report  and  then  votes.  If  rejected,  the  proposal  goes  back  to  the 
Users  Group  for  reconsideration.  If  approved,  the  proposed  change  becomes  a 
candidate  for  the  next  revision  to  the  standard  subject  to  the  final 
approval  or  disapproval  of  the  Designated  Control  Agent. 

The  primary  criterion  for  accepting  a  change  is  maintaining  upward  compatibility 
with  the  hardware.  Some  changes  have  been  judged  to  be  of  the  type  required  to 
correct  a  problem.  These  will  diminish  as  the  standard  matures.  Some  changes 
are  approved  on  the  basis  of  clarification  or  interpretation.  These  changes  are 
usually  initiated  because  of  misunderstanding  or  misinterpreting  the  standard. 
Caution  now  must  be  used  as  extensions  are  proposed  to  give  added  capabilities 
or  increase  performance.  The  Air  Force  will  not  benefit  from  ISA  standar¬ 
dization  unless  the  standard  is  stable  enough  for  manufacturers  to  design  to, 
set  up  production  and  be  competitive. 

A  Mature  Standard 


MIL- STD- 1750A  was  derived  from  the  DAIS  AYK-15  ISA.  Industry  was  later  invited 
to  review  and  comment  on  the  standard.  The  basic  standard  was  published  on  21 
February  1979,  after  three  reviews.  The  Users  Group  was  established  in  August 
1979  with  over  AO  systems,  computer  and  software  companies  participating.  The 
"A"  version  was  published  in  July  1980  after  four  meetings  of  the  Users  Group. 
The  "A"  version  added  the  expanded  memory  options  and  other  clarifications. 

Since  then  the  Users  Group  has  continued  to  meet  and  further  refine  the  stan¬ 
dard.  Change  Notice  1,  which  corrects  some  problems  in  the  expanded  memory 
update  and  incorporates  the  built-in-function  options,  will  be  formally 
published  in  July  1982.  The  Control  Board  decided  that  the  standard  would  be 
frozen  for  three  years.  Additional  changes  will  be  considered,  but  will  not  be 
incorporated  formally  until  this  stabilizing  period  has  lapsed. 

An  indication  to  the  maturity  of  the  standard  is  the  number  of  Air  Force  systems 
now  incorporating  MIL-STD-1750A.  These  are: 


F-16  MSIP  Fire  Control  Computer 

Delco  Electronics 

LAMTIRN  POD 

Delco  Electronics 

F-16  MSIP  Equipment 

Fairchild 

Wide  Field-of-View  HUD  for 

F-16  and  A- 10 

Marconi 

F— 111  Computer 

Singer-Kearf ott 

F-5G  Computer 

Teledyne 

F-5G  Radar  (G.E) 

Tracor 

MATE 

Sperry  Univac 

B-l  Radar 

Westinghouse 
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Verification 


Verification  is  the  process  the  Air  Force  uses  to  ensure  that  a  vendor's  com¬ 
puter  complies  with  MIL-STD-1750A.  The  Architectural  Test  Procedure  (ATP)  is 
conducted  by  SEAFAC  personnel.  The  test  checks  only  the  ISA.  It  does  not  test 
for  through-out  performance  or  specification  compliance.  It  is  not  an  accep¬ 
tance  test.  The  verification  test  is  conducted  by  hand-loading  some  com¬ 
munication  routines  that  enable  loading  the  verification  test  software.  Once 
this  is  done,  the  machine  tests  itself  by  performing  instruction  according  to 
the  software  and  comparing  the  results.  The  results  are  downloaded  and  used  to 
write  a  test  report.  The  report  describes  the  areas  where  the  computer  meets  or 
fails  to  meet  the  standard.  The  test  report  is  given  only  to  the  organization 
requesting  the  verification  test. 

Arrangements  for  the  verification  test  are  made  by  letter  to  Mr.  Ron  Vokits, 
ASD/AXT,  Wright-Patterson  AFB,  OH  45433.  The  contractor  must  include  the 
following  within  the  processor  -to  be  tested: 

a.  64K  of  memory  (test  can  be  performed  with  32K) 

b.  Front  panel  capability 

c.  RS-232  I/O  channel  controlled  by  XIO  commands 

d.  Software  subroutines  to  allow  communication  over  the 
RS  232  channel. 

The  government  provides  all  other  software  involved  in  the  architectural  test 
procedure. 

Summary 

It  is  the  job  of  the  MIL-STD-1750A  Control  Agent  to  manage  and  control  the 
standard.  The  Control  Process  has  been  documented  and  is  functioning.  The 
standard  is  mature  and  is  frozen  for  three  years.  Another  part  of  the  job  is  to 
ensure  that  MIL-STD-1750A  is  correctly  implemented.  This  job  is  done  by  the 
Control  Facility  by  using  the  Architectural  Test  Procedure.  A  similar  control 
process  has  been  set  up  for  the  MIL-STD-1589B  (JOVIAL). 
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AND  PROCEDURES  TO  PROCESS  WAIVERS 


ORGANIZATIONS  INVOLVED 


USERS 


PROGRAM  APPLICATIONS 


VERIFICATION 


USERS 


MRASM-3155 


TRANSITION  PLAN  TO  UPGRADE  THE  DIGITAL  INTEGRATING  SUBSYSTEM 

TO  MIL- STD- 1750 A  FOR  MRASM 


ABSTRACT 


J .  B .  Reed 

MRASM  Chief  Engineer 


F.  W.  Purdy 

MRASM  Chief  Product  Software 


The  Medium  Range  Air  to  Surface  Missile  (MRASM),  currently  in 
development  for  joint  Air  Force  and  Navy  usage,  employs  an  array 
of  micro  processors  to  perform  on-board  computation.  Because  of 
program  schedule,  which  calls  for  IOC  in  1985,  and  because  of 
severe  size,  weight,  environmental,  and  power  constraints,  the 
architecture  uses  two  Z8000  based  Digital  Integrating  Subsystem 
(DIS)  computers  developed  in  1978-1980  for  the  AF  Armament 
Division.  The  evolution  of  the  F-16  MSIP  LSI  chip  processor 
and  support  software,  MIL-STD-1750A ,  and  DIS  hardware  allows  an 
orderly,  minimum  cost,  transition  development  to  MIL-STD-1750A. 
The  result  of  the  DIS  transition  effort  will  be  a  state-of-the- 
art  processor  and  support  software,  which  will  be  directly 
applicable  to  MRASM,  and  may  find  broader  future  application. 

This  paper  addresses  the  transition  plan  to  upgrade  DIS  to  1750A. 
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BACKGROUND 


The  Digital  Integration  Subsystem  (DIS)  Computer  has  been 
developed  and  flight  test  demonstrated  over  the  past  several  years 
to  fill  the  Air  Force's  need  for  a  small,  lightweight,  low  power, 
missile-borne  processor  system.  During  the  initial  phases  of  its 
evolution,  the  best  available  single  chip  microprocessor  for  that 
application  was  the  Z8000,  and  it  was  used  as  the  core  element  in 
the  system.  A  great  deal  of  flight  hardware,  (especially  missile 
tailored  I/O  support),  test  software,  and  development  support 
software  has  been  created  in  support  of  its  application  both  in 
the  Air  Force  Midcourse  Guidance  Demonstration  (MGD)  program,  and 
for  the  Medium  Range  Air  to  Surface  Missile  (MRASM)  program. 

During  the  development  of  DIS,  MIL-Standard  1750  matured  to 
Mil-Standard  1750A,  the  value  of  the  standard  became  widely  under¬ 
stood  and  accepted  and  the  F-16  MISP  program  undertook  the  develop¬ 
ment  of  both  a  low  cost,  single  chip  processor  that  can  execute 
the  full  instruction  set  and  an  elegant  set  of  development  support 
software.  But  the  need  for  the  low  cost,  low  power  standardized 
missile-borne  processor  remains  a  real  one,  and  the  MRASM  program 
is  committed  to  upgrade  its  processors  to  MIL-STD-1750A. 

The  first  five  figures  depict  the  DIS  1A  hardware,  its  en¬ 
vironmental  requirements  and  implementation  groundrules,  the  DIS 
1A  hardware  provided  to  MRASM  as  legacy,  the  MRASM  hardware 
development,  the  DIS  support  software  provided  as  legacy,  and  the 
MRASM  developed  support  software. 

TRANSITION  PLAN  OVERVIEW 

A  management  assessment  of  MRASM  requirements,  existing  hard¬ 
ware  and  software,  and  MS IP  program  plans  and  status  was  made. 

This  assessment  resulted  in  the  following  groundrules: 

•  Full  Compliance  with  MIL-STD-1750 

-  Ensures  maximum  utilization  of  software  tools 

-  Allows  use  of  future  S/W  tool  enhancements 

-  Provides  floating  point  and  other  instruction  set 
advantages 

•  Minimum  Program  Nonrecurring  Cost  through: 

-  Maximum  retention  of  MRASM/DIS  I/O  hardware 

-  Black  box  functional  identicality 

-  Maximum  utilization  of  F-16  MSIP  support  software 

-  Maximum  use  of  MRASM  J-73  application  software  through 
recompilation 


TRANSITION  PLAN  OVERVIEW  (Continued) 


•  Use  MSIP  VLSI  CPU  chips  to  retain  low  cost  advantage  of 
single  chip  microprocessor 

•  Schedule  to  emplace  all  hardware  and  support  software 
paced  by  VLSI  development 

•  Flight  test  qualify  1750  computers  and  S/W  MRASM  variant 

Figure  6  pictorially  depicts  the  overall  hardware/software 
transition  elements  and  strategy  broken  down  into  the  three 
major  elements;  flight  hardware,  flight  and  support  software, 
and  test  hardware  and  software. 

As  can  be  seen,  DIS  provides  a  basic  flight  qualified 
package  of  the  packaging  standards  and  the  high  technology  memory 
elements  which  can  all  be  reused  directly  in  the  1750  DIS.  MRASM 
provides  all  of  the  system  peculiar  I/O.  The  VLSI  chips  from 
MSIP  will  be  used  to  provide  the  core  processing  elements.  The 
transition  plan  modifies  the  I/O  controller  as  well  as  the  memory 
controller  to  conform  to  the  split  I/O  and  memory  buses,  and 
develops  the  CPU  board. 

MSIP  will  provide  the  core  elements  for  the  1750  DIS  support 
software:  the  JOVIAL  cross-compiler  and  1750A  cross  assembler. 
Modifications  to  the  existing  DIS  linker  loader  and  DIS  inter¬ 
pretive  computer  simulator  will  interface  the  MSIP  compiler  and 
assembler  to  the  software  debug  and  test  tools  implemented  on 
MRASM.  Transition  of  the  MRASM  Operational  Flight  Software 
(OFS)  to  1750  DIS  will  require  recoding  of  the  DIS  operating 
system  only;  applications  tasks  can  be  recompiled  from  the  JOVIAL 
source . 

In  the  area  of  hardware  test,  since  only  three  cards  are 
changing,  and  black  box  functional  identicality  can  be  enforced, 
only  a  minimum  set  of  new  hardware  and  software  is  required 
as  shown . 

HARDWARE  DEVELOPMENT  PLAN 

Figure  7  details  the  current  estimate  of  hardware  design 
parameters  for  the  three  circuit  boards  requiring  change. 

Figure  8  showns  the  hardware  development  shcedule  currently 
in  work  to  develop  the  1750  DIS  boards  and  units. 
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FLIGHT  AND  SUPPORT  SOFTWARE  DEVELOPMENT 


The  MRASM  transition  to  1750  requires  rehosting  the  existing 
OFS  developed  for  DIS  1A  and  revalidating  the  rehosted  OFS.  For 
the  majority  of  the  OFS,  written  in  MIL-STD-1589  A  and  B  compatible 
JOVIAL,  this  is  accomplished  by  recompiling  the  source  code  with 
the  MSIP  compiler.  As  shown  in  Figure  9,  the  common  DIS  operating 
system  and  certain  routines  in  the  guidance  and  navigation  computer 
are  written  in  assembly  language.  These  will  be  translated  to  the 
MSIP/IEEE  Standard  1750A  assembly  language  and  reassembled. 

The  support  software  suite  required  for  the  MRASM  OFS  rehost 
is  produced  by  a  marriage  of  MSIP  and  DIS  1A  tools.  The  MSIP 
JOVIAL  compiler  and  1750A  assembler,  depicted  in  Figure  10,  will 
be  used  unmodified.  Modifying  the  MRASM  DIS  Linker  Loader  (DLL) 
provides  the  interface  to  existing  DIS  software  load,  debug,  and 
test  tools.  Figure  11  shows  the  DLL  modified  to  accept  the  re¬ 
locatable  object  and  relocatable  debug  files  as  produced  by  the 
MSIP  programs.  DLL  builds  an  absolute  load  file  that  includes 
debug  data  supporting  interactive  symbolic  (JOVIAL  level)  debug 
using  the  DIS  test  tools. 

DIS  Control-Monitor-Load  (CML)  is  one  of  the  programs  that 
accepts  the  DLL  loadfile.  As  described  in  Figure  11,  CML 
executes  on  a  DIS  Diagnostic  Station  (DDS)  providing  interactive 
download  and  software  debug  capabilities  with  a  DIS  target  computer. 
CML  will  require  minor  modification  to  download  to  a  1750  DIS. 

MRASM  is  developing  a  DIS  interpretive  computer  simulator  to 
provide  flexibility  and  high  visibility  during  unit /subprogram 
checkout  in  an  environment  that  decouples  early  hardware  and 
software  testing.  The  DIS  ICS,  shown  in  Figure  12,  accepts  the 
DLL  loadfile  and  has  the  same  interactive  user  interface  as  CML. 
Several  approaches  to  developing  a  1750  DIS  ICS  are  being  traded. 

Figure  8  shows  the  plan  for  developing  the  1750  DIS  support 
software  tools. 
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REPACKAGED  POWER  SUPPLY 


Convair  Division 

!  1  AND  1A  PROJECT  DEVELOPED  A  BASIC  COMPUTER  FOR  MISSILE-BOUND  APPLICATION 


FIGURE  3 


MRASM  PECULIAR  REQUIREMENTS  INTRODUCED  ADDITIONAL  CHANGE  TO 

DIS  IA 


FIGURE  4 


SUPPORT  SOFTWARE  SYSTEM  DEVELOPED  BY  DIS  BEING  UPGRADED  FOR  MRASM 
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FIGURE  5 


DIS-1750  TRANSITION  IS  STRAIGHT  FORWARD  APPLICATION  OF  EXISTING  AND  AONHITTtD 
TECHNOLOGY  DEVELOPMENT 
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WASP  WEAPON  SYSTEM/DIGITAL  PROCESSING 


Lt  Gene  J .  Dylewski 
Lt  Don  R.  Huckle 
Air  Force  Armament  Division 
Eglin  AFB,  Florida 

ABSTRACT 

This  paper  provides  a  summary  of  the  Wasp  weapon  system  and  discusses  the 
inherent  digital  processing  electronics  and  requirements.  It  addresses  the 
applicability  of  MIL-STD-1 750A  (Airborne  Computer  Instruction  Set  Architecture) 
and  MIL-STD-1 589B  (Military  Standard  Jovial  J73)  to  the  Wasp  system  and  invites 
replies  from  members  of  the  microprocessor  technology  community  as  to  alter¬ 
native  digital  processing  solutions. 

WASP  WEAPON  SYSTEM/DIGITAL  PROCESSING 

The  Wasp  program  goal  is  to  provide  the  Air  Force  with  an  air-to-ground 
missile  for  use  against  massed  armor  in  a  Battlefield  Interdiction  role.  The 
Wasp  system  is  being  designed  to  provide  multiple  armor  kills  from  a  single 
aircraft  pass  against  any  massed  armor  configuration.  Missiles  can  be  launched 
singularly  or  in  selected  salvos  from  high  or  low  altitudes  without  exposing  the 
aircraft  to  terminal  defenses.  Missiles  are  capable  of  being  launched  within  the 
entire  flight  envelope  of  the  current  and  advanced  tactical  fighter  aircraft. 
Primary  Air  Force  aircraft  are  shown  in  Figure  1  and  NATO  aircraft  considered 
for  Wasp  employment  are  also  listed. 

The  primary  mode  of  operation  for  Wasp  is  the  standoff  blind  launch  mode 
where  the  aircraft  does  not  visually  acquire  the  targets.  Illustrations  of  the 
blind  launch  timeline  and  the  Wasp  delivery  are  shown  in  Figures  2  and  As 
seen  in  Figure  2,  the  missile  seeks  its  cruise  altitude  after  launch  and  flies 
towards  the  target  array.  The  millimeter  wave  (MMW)  seeker  and  its  associated 
signal  processing  provide  each  missile*  s  digital  processor  with  guidance  and 
targeting  information.  The  digital  processor  combines  seeker  data  with  flight 
sensor  information  to  provide  for  autonomous  lock-on- after- launch  capability  in 


adverse  weather  and  battlefield  conditions.  Flexibility  of  launch  modes  allow 
for  single  missile  launches  in  a  Point  and  Shoot  mode  for  Close  Air  Support  ml r: i 

The  Wasp  program  began  the  validation  phase  in  Nov  1  979  with  the  award  of 
competitive  42-month  contracts  to  Boeing  Aerospace  Co.  and  Hughes  Aircraft  Co. 

Main  emphasis  throughout  the  validation  phase  has  been  on  the  MMW  seeker  devel¬ 
opment  and  testing.  After  a  thorough  evaluation  in  Feb  1982,  the  Air  Force 

9 

System  Program  Office  elected  to  continue  the  validation  program  with  Hughes. 

The  Hughes  seeker  has  undergone  static  testing  and  is  currently  in  captive 
flight  testing.  The  validation  phase  will  end  with  the  launching  of  eight 
single  free-flight  missiles  from  an  F-16  aircraft  at  Eglin  AFB,  beginning  in  Nov 
1982.  Full  Scale  Development  (FSD)  will  begin  immediately  after  completion  of 
validation. 

The  Hughes  missile  configuration  is  shown  in  Figure  4.  Each  pod  is  envi¬ 
sioned  to  contain  twelve  missiles  which  are  packaged  tandem  in  six  launch  tubes. 
The  pod  is  roughly  the  size  of  an  F-16  370  gallon  fuel  tank.  This  All  Up  Round 
is  a  2000  pound  class  store.  Each  missile  weighs  slightly  over  100  pounds  and 
is  approximately  five  feet  in  length.  The  four  wings  and  four  control  fins 
fold  to  allow  high  packaging  density.  The  wings  and  fins  open  after  missile 
launch. 

Flexibility  in  deployment  tactics  will  be  required  to  provide  the  best 
possibility  for  success  on  every  mission.  Launch  aircraft  will  carry  two  or 
four  Wasp  pods  on  each  mission.  For  the  massed  armor  scenario,  the  aircraft  typi¬ 
cally  ingresses  at  a  low  altitude  for  maximum  survivability,  fires  all  its 
missiles,  jettisons  the  empty  pods,  and  egresses  as  the  missiles  fly  on  to  their 
assigned  targets.  Jettisoning  the  empty  pods  rather  than  returning  them  for 
refurbishment  is  part  of  a  "wooden  round"  maintenance  approach  being  pursued  for 
its  low  total  system  life  cycle  cost.  The  Wasp  missile  system  must  be  available 
when  needed  and  reliable  when  deployed.  Additionally,  the  system  must  be  econo¬ 
mical  to  support  and  deploy.  The  wooden  round  concept  requires  no  field 
checkout  other  than  that  associated  with  the  Life  Cycle  Surveillance  Test 
Program.  Cost  and  supportability  are  major  factors  influencing  the  eventual 
Wasp  configuration. 


.,rp  faces  several  technology  challenges  during  development.  Although  the 
c:..jcr  emphasis  is  now  on  the  MMW  seeker,  other  technologies  being  demonstrated 
i:  rlude  folding  wings/fins,  high  boost  to  sustain  propulsion  ratios,  warhead 
penetration,  and  high  speed  digital  processing.  High  speed  launch  imposes  great 
demands  on  the  missile  during  the  early  phase  of  the  mission.  Control  surfaces 
must  be  quickly  deployed  and  boost  must  be  sufficient  to  clear  the  aircraft. 
Launch  requirements  for  aircraft  separation  are  contradictory  to  the  requirement 
for  a  moderate  cruise  velocity  during  seeker  search.  The  Hughes  missile  design 
employs  separate  boost  and  sustain  motors  to  meet  this  requirement.  The  warhead 
under  development  is  a  hit-to-kill  shaped  charge.  The  conflicting  requirements 
for  small  size  and  weight  vs  the  requirements  for  armor  penetration  are  driving 
the  design. 

Another  important  subsystem  of  the  Wasp  missile  is  the  guidance  electronics. 
Navigation  performance  must  be  matched  with  the  requirements  to  build  an  affor¬ 
dable  missile  with  acceptable  performance.  The  relatively  short  flight  of  the 
missile  allows  some  relaxation  in  the  midcourse  guidance  requirements.  Several 
other  factors  influence  midcourse  guidance  requirements,  among  these  are: 
seeker  search  area,  missile  attack  pattern  and  angle,  and  target  location 
errors.  Hughes'  design  incorporates  rate  gyros  and  accelerometers  to  provide  an 
attitude  hold  system.  This  approach  matches  the  missile  attack  pattern,  target 
allocation  scheme,  and  seeker  search  areas.  Analytical  demonstrations  of  the 
required  kills  per  pass  have  been  accomplished  for  the  expected  nominal  launch 
conditions  as  well  as  for  realistic  battlefield  variations  from  nominal. 

The  key  to  success  of  the  Wasp  program  is  the  ability  of  the  MMW  seeker/ 
signal  processor  and  associated  electronics  to  detect,  acquire  and  guide  the 
missile  to  a  valid  target  impact.  A  large  part  of  this  ability  depends  on 
state-of-the-art  high  speed  microprocessor  technology.  The  digital  processing 
unit  must  coordinate  large  amounts  of  guidance  and  targeting  information,  per¬ 
form  data  computations  and  manipulations,  and  control  all  of  the  functional 
tasks  from  pre- launch  to  impact.  The  electronics  must  perform  with  flawless 
accuracy  and  nearly  100?  reliability  to  meet  system  requirements.  More  impor¬ 
tantly,  the  Hughes'  design  places  stringent  requirements  on  the  digital  pro¬ 
cessing  design  in  terms  of  processing  speed,  memory  capacity,  size,  weight  and 
power  dissipation. 


In  Wasp  as  in  most  other  modern  tactical  missiles,  the  central  processing 
unit  (CPU)  or  data  processor  is  one  of  three  major  components  of  the  digital 
processor.  The  other  two  components  are  the  input/output  (I/O)  and  signal  processor 
(referred  to  as  the  video  processor  in  Wasp).  The  CPU  performs  most  of  the 
logical  and  medium  speed  computations  involved  in  missile  guidance.  In  Wasp 
these  data  processing  functions  are: 

a.  Missile  Guidance 

b .  Seeis-er  Control 

c .  Signal  Processing 

d .  System  Control 

All  of  these  processes  are  characterized  by  data  rates  that  are  dependent  upon 
missile  time  constraints. 

Digital  signal  processing  of  high  speed  data  (at  sensor  rates)  is  pro¬ 
cessed  by  the  video  processor.  This  is  currently  a  block  of  high  speed  dedi¬ 
cated  logic  that  performs  functions  such  as  digital  filtering,  Discrete 
Fourier  Transformation  calculations,  detection,  post  detection  integration, 
and  range  gate  buffering.  The  I/O  subsystem  performs  various  conversions, 
timing  and  logic  functions  such  as  range  gate  and  transmitter  control,  A/D 
and  D/A  conversion. 

The  Wasp  missile  processor  operates  in  a  multi-tasking  mode  taking  data 
from  a  number  of  different  sources  and  responding  within  restricted  timing 
constraints.  The  Wasp  processor  must  be  capable  of  high  speed  iterated  numeri¬ 
cal  operations  on  arrays  of  data  and  also  be  capable  of  rapid  decision  func¬ 
tions  for  mode  control  and  detection  algorithms.  This  type  of  application 
requires  a  number  of  architectural  attributes: 

a.  HIGH  SPEED.  The  Wasp  processor  requirements  are  in  excess  of  2.0  million 
instructions  per  second  (MIPS).  A  slower  processor  could  be  used,  but  this  would 
require  the  off  loading  of  a  number  of  software  functions  to  the  video  processor  and 
I/O  hardware,  and  may  exceed  volume  constraints. 


b.  VECTORED  INTERRUPT  CAPABILITY. 


The  Wasp  processor  must  quickly 
respond  to  many  different  asynchronous  data  sources.  Task  scheduling  func¬ 
tions  must  be  performed  in  hardware.  The  time  required  for  saving  and 
restoring  system  logic  states  must  be  minimal. 

c.  EFFECTIVE  MEMORY  ADDRESSING.  Transfers  of  large  arrays  of  information 
dictate  a  high  speed  addressing  structure. 

d.  HIGH  SPEED  DECISION  LOGIC.  The  large  number  of  Wasp  system  flight  modes 
and  complex  detection  logic  require  a  conditional  branch  mechanism  which  is  the 
speed  equivalent  of  a  simple  add  instruction. 

e.  RAPID  ARITHMETIC.  High  speed  multiplication  and  addition  are  essen¬ 
tial  to  the  numerical  tasks  in  missile  guidance.  Presently,  floating  point 
operations  induce  speed  and  hardware  penalties.  However,  from  a  programming 
standpoint,  floating  point  capability  would  be  very  useful. 

Table  1 .  is  a  summary  of  the  Wasp  missile  processor  requirements: 


Table  1  .  Missile  Processor  Physical  Constraints 

Size:  24  in2  (PC  Board  Area) 

Power  Dissipation:  10  Watts 

Temperature  Range:  -55 °C  to  125 °C  Ambient 
Qualification  Levels:  Mil-Spec-885  Level  B. 
Throughput:  2  MIPS  (Fixed  Point,  "Missile  Mix" 
Instruction  Mix) 


Existing  software  support  tools  are  essential  for  software  development. 
Missile  applications  require  programming  and  debugging  aids  that  are  used  in 
other  computer  applications  with  minor  additions.  The  Wasp  processor  must  be 
supported  by  a  symbolic  assembler,  a  linking  loader,  hardware  diagnostic  programs 


and  an  emulation  program  hosted  on  peripheral  computers.  The  emulator  must 
keep  track  of  system  timing  in  a  very  exact  manner  and  be  capable  of  simultaneous 
accecs  by  a  number  of  programmers.  Additionally,  the  Wasp  processor  development 
system  requires  a  monitoring  system  for  the  missile  processor.  This  system  must 
be  capable  of  multiple  breakpoints,  bus  monitoring  and  software  trace  capability. 
The  monitoring  equipment  must  not  interfer  with  program  execution  speed. 


The  throughput  figure  identified  in  Table  1 .  needs  further  elaboration.  The 
speed  of  the  processor  is  dependent  upon  the  frequency  and  the  types  of  instruc¬ 
tions  to  be  executed.  In  the  case  of  Wasp,  the  Radar  Signal  Processing  software 
presents  the  greatest  amount  of  the  time  loading.  Design  reparti tioning  to 
offload  a  number  of  software  functions  to  the  video  processor  and  I/O  hardware 
would  reduce  the  timeloading  but  would  result  in  a  major  redesign  effort.  This 
may  or  may  not  be  possible.  Table  2  presents  the  Wasp  instruction  mix/ throughput 
for  the  critical  path  software  -  Radar  Signal  Processing: 


Table  2.  Wasp  Instruction  Mix/Throughput 

Critical  Path:  Radar  Signal  Processing 

Static  Program  Memory:  5000  Instructions 
Sample  Period:  4.8  msec 

$  Time  Loading/Execution  Time:  46$/2.2  msec 


Mix: 

Load  and  Store  40$ 
Add  and  Subtract  10$ 
Test  and  Branch  15$ 
Logical  Compare  1 5$ 
Shift  (3  Bit  Average)  5$ 
Multiply  2$ 
Divide  1$ 
Double  Precision  1$ 


Miscellaneous  (i.e.,  Jumps,  Go  Subs)  11$ 


I.’ie  Hughes'  validati Lissiut  processor  design  incorporates  their  company 
-e'v  t  I  oped  General  Missile  Processor  (GK?).  The  GMP  is  a  high  speed  programmable 
:■  .ni computer  composed  of  Schottky  TTL  hybrids.  It  was  first  designed  in  1974, 

•  pacifically  for  missile  signal  processing  and  guidance  functions.  The  GM?  has 
been  adapted  and  used  on  several  other  missile  programs,  among  them  are:  the 
Pncenix  missile,  the  Advanced  Medium  Range  Air-to-Air  Missile  (AMRAAM),  and 
Tank-Breaker.  The  GMP  has  been  modified  into  the  Wasp  Digital  Processor  (WDP) 
processing  2.1  MIPS  of  the  missile/ guidance  instruction  mix.  It  is  this  single 
characteristic  which  sets  the  WDP  apart  from  other  available  commercial  signal  pro¬ 
cessors  or  federated  microprocessor  schemes.  In  its  hybrid  form,  the  WDP  dissipates 
101  watts  of  power.  It  has  been  form  factored  for  use  in  the  free- flight  missiles. 
Further  reduction  in  size  is  necessary  for  the  Wasp  FSD  configuration  in  order  to 
meet  size,  weight  and  power  constraints. 

Air  Force  Systems  Command  requirements  for  Embedded  Computer  Resources  (ECR) 
specify  that  all  ECR  shall  be  developed  in  accordance  with  MIL-STD-1 750A 
(Airborne  Computer  Instruct  Set  Architecture)  and  MIL- STD- 1 589B  (Military 
Standard  Jovial  J73)>  In  addition  to  the  above  standards,  the  Wasp  FSD 
Statement  of  Work  will  require  that: 

a.  Embedded  computer  hardware  shall  include  a  minimum  of  30  percent  spare 
capacity  in  terms  of  memory  and  throughput. 

b.  Preassembled,  off-the-shelf  microcomputers  or  minicomputers  shall  be 
used  unless  it  can  be  shown  that  no  such  technology  exists  which  satisfy 
appropriate  form-fit  and  function  requirements. 

c.  Support  tools  shall  include  an  efficient  compiler  for  an  AFSC  approved 
high  order  language. 

d.  The  computer,  its  memories  and  peripherals,  shall  be  modular  in  design 
and  shall  be  designed  for  FSD  ease  of  maintenance. 

e.  In  no  case  will  the  development  of  an  assembler,  compiler,  or  operating 
system  be  undertaken. 


Ideally,  the  Wasp  design  must  utilize  c.  r'-zcessor  that  meets  all  of  the  pre¬ 
vious  standards  and  requirements.  To  our  ledge,  no  commercial  micropro¬ 
cessor  scheme  and  support  software/ periphery.  equipment  exists  that  meets  all 
of  these  requirements.  It  is  the  intent  r.f  this  paper  to  invite  replies  from 
members  of  the  computer  technology  community  as  to  the  present  and  future 
availability  of  microprocessor  technology  which  will  meet  Wasp  unique  digital 
processing  requirements  and  military  standards. 

Wasp  poses  several  technological  challenges.  It  is  the  first  tactical 
missile  weapon  to  use  a  millimeter  wave  sensor.  The  warhead,  constrained  by  the 
physical  missile  size,  must  be  capable  of  lethal  penetration  of  the  latest 
threat.  Controlling  the  missile  are  sophisticated  signal  processing  electronics 
which  autonomously  detect,  acquire,  track  and  guide  the  missile  to  a  direct  hit. 
Inherent  in  Wasp  is  the  need  for  state-of-the-art  digital  processing  technology 
which  meets  system  requirements.  Any  questions  concerning  this  paper  should  be 
addressed  to  Headquarters  Armament  Division,  Deputy  for  Antiarmor  Munitions, 
Eglin  AFB,  FL,  Attention  Lt  Gene  Dylewski,  (904)  882-5868,  AV  872-5868. 
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FIGURE  1.  WASP  LAUNCH  AIRCRAFT 
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FIGURE  3,  WASP  BASIC  MODE  SCENARIO 
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PROCESSOR  REQUIREMENTS 


CRITICAL  PROCESSING  PATH 
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COMPUTER  RESOURCE  REQUIREMENTS 
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ABSTRACT  encountered.  The  standards  idea 


Delco  Electronics  early  acceptance 
of,  and  participation  in.  Air  Force 
activities  with  standardized  Military 
computers  is  reviewed.  The  early 
acceptance  and  in-house  development 
of  MIL -STD— 175  OA  architecture  compu¬ 
ters  enabled  Delco  Electronics  to 
capture  Air  Force  programs  requiring 
this  new  standard.  These  early  pro¬ 
grams  are  detailed,  and  Delco 
Electronics  plans  for  the  evolution 
of  computers  operating  to  this 
architecture  standard  are  discussed . 

INTRODUCTION 

The  move  toward  computer-oriented 
standards  began  at  Wrlght-Patterson 
Air  Force  Base  with  the  MIL-STD-1553 
Multiplex  Data  Bus  Conference  in 
1976.  Milestones  that  followed 
included  the  introduction  of  MIL-STD- 
1750  itself,  the  creation  of  the 
User's  Group  in  August  1979.  and  the 
establishment  of  the  Embedded  Compu¬ 
ter  Standardization  Program  Office. 

Although  Delco  Electronics  monitored 
these  activities,  new  standards 
(1553.  1750,  etc)  were  initially  met 
with  resistance  from  the  Delco  Elec¬ 
tronics  working  groups,  no  doubt 
because  of  the  not-invented-here 
attitude  that  is  so  often 


generated  interest  among  key  people, 
however ,  so  that  we  were  able  to. 
muster  sufficient  support  within 
Delco  □.ectronics  to  begin  studies  of 
both  the  hardware  and  software  impli¬ 
cations.  These  studies  eventually  led 
to  the  conclusion  that  hardware 
incorporating  this  instruction  set 
architecture  (ISA)  could  be  built, 
and,  perhaps  more  importantly,  this 
ISA  would  solve  avionics  problems  as 
we  knew  them.  Finally,  it  appeared 
that  standardization  at  the  ISA  level 
would  allow  introduction  of  new 
devices  and,  hence,  new  computers  as 
time  progressed.  Furthermore,  it 
appeared  that  this  approach  would  not 
inhibit  future  computer  development 
plans.  Nothing  we  have  experienced  so 
far  suggests  that  our  analysis  was 
wrong . 

CURRENT  MIL-STD-1750A  PROGRAMS 

Delco  Electronics  competed  for  and 
secured  the  first  two  Air  Force  pro¬ 
grams  requiring  computers  executing 
the  MIL-STD-1 750A  instruction  set 
architecture.  About  18  months  ago, 
the  computers  for  the  Low  Altitude 
Navigation  Targeting  Infrared  Night 
(LANTIRN)  program  was  competed,  and 
Deleo  Electronics  was  selected  by 
Martin  Marietta,  Orlando  Division 
(Contract  745528),  to  supply  its  M372 


MIL-STD-175 OA  computer  with  solid 
state  memory.  Production  options  for 
300  shipsets  (600  computers)  have 
been  proposed.  Some  5  months  later, 
a  decision  was  made  to  introduce  MIL- 
STD-1 750A  into  the  F-16  aircraft  as 
part  of  the  General  Dynamics  Multi¬ 
national  Staged  Improvement  Program 
(MSIP) .  Again,  the  requirement  was 
competed,  and  Delco  Electronics  was 
selected.  Negotiations  are  now  com¬ 
plete  (General  Dynamics  purchase 
Order  149)  for  production  options  of 
up  to  1,800  shipsets  (1,800  compu¬ 
ters)  with  core  memory.  The  principal 
characteristics  of  these  two  programs 
and  their  computer  configurations  are 
shown  in  Figure  1. 

DELCO *S  M372  MIL-STD-1750A  COMPUTER 

Architecturally  Enhanced  CPU 

The  M372  computer  utilizes  a  compact, 
high  performance  processor  mechanized 
with  advanced  LSI  circuits  to  achieve 
an  optimal  balance  of  performance, 
power,  and  size.  The  organization  is 
implemented  in  a  highly  efficient, 
pipelined  structure  that  allows  each 
instruction  to  be  executed  in  a  mini¬ 
mus  of  time. 

The  CPU  is  implemented  using  the  2900 
family  of  commercially  available  LSI 
devices  and  is  optimized  to  effi¬ 
ciently  execute  the  MIL-STD-175 OA 
instruction  set.  To  achieve  the 
highest  possible  throughput  consis¬ 
tent  with  cost  and  power ,  the  design 
is  based  on  the  use  of: 

e  24-bit  arithmetic  unit  and 
multiplier 

•  Instruction  lookahead  buffer  to 
reduce  instruction/operand  memory 
contention 

•  Concurrent  memory  and  1/0  data 
flow. 

High  throughput  is  achieved  primarily 
through  architectural  sophistication. 


However,  some  increase  in  speed  comes 
from  the  use  of  high  speed,  bipolar, 
bit- si  ice  LSI  devices  and  Schottky 
transistor-transistor  logic.  The  CPU 
uses  pipelining  to  fetch  an  instruc¬ 
tion  while  executing  the  previous 
one;  buffering  is  provided  for  up  to 
sixteen  16-bit  instruction  words.  The 
effect  of  instruction  pipelining  is  a 
submicrosecond  execution  rate  for 
fixed-point,  short  instructions.  The 
microcode  cycle  (clock  time  to 
execute  logic  control  for  one  micro¬ 
store  word)  is  187  nanoseconds.  The 
processor  optimizes  internal  bus 
traffic  by: 

•  Providing  separate  address  and 
data  memory  Interface  (MI)  buses 
to  provide  the  fastest  memory 
access  and  instruction  and  data 
fetches. 

•  Providing  a  dedicated  programmed 
1/0  (PIO)  bus,  which  minimizes 
loading  on  the  critical  memory 
interface  bus  and  permits  separa¬ 
tion  of  programmed  1/0  activity 
from  the  memory  interface,  thereby 
preventing  asynchronous  input/ 
output  from  degrading  instruction 
throughput . 

For  configurations  employing  a  core 
memory,  the  use  of  memory  inter¬ 
leaving  minimizes  the  transport  time 
required  to  fetch  data  from  the  16- 
bit  memory  subsystem.  Multiplexing 
memory  modules  on  the  same  basic 
memory  bus  achieves  economies  in  the 
electronics  and  increases  the  utility 
of  the  bus  system.  The  basic  bus 
organization  allows  the  use  of 
single-  or  dual- interleaved  memories 
as  well  as  a  variety  of  semiconductor 
memory  types. 

The  CPU  is  microprogrammed ,  with 
approximately  25  percent  spare  con¬ 
trol  store  for  future  growth.  The 
control  store  is  organized  to  perform 
both  instruction  mapping  and 
sequencing  and  control.  Instruction 
mapping  translates  instruction  code 


2 


1 


Oelco  Electronics  M372 
F-16  Fire  Control  Computer 


Instruction  Set 

Size 

Weight 

Power 

Throughput 

Memory 

Input/Output 


Reliability 


MIL-STD-1750A;  MIL-STD-1589B  HOL 
1/2-ATR  by  18.6  inches 
31.3  pounds 

280  watts  (3-phase,  400-hertz,  1 1 5-volt  source) 

587  KOPS  (DAIS  instruction  mix) 

Two  32k  core  modules;  750ns  cycle  time;  16  bits  plus  parity 
Discretes  (26  input;  8  output) 

Analog  (6  dc  input;  2  synchro  output) 

MIL-STD-1553B  data  bus  (two  channel  dual-redundant,  multiprotocol) 
DMA  (greater  than  1  million  words  per  second 

2,403  hours  mean  time  between  failures 


Oelco  Electronics  M372 
LANTIRN  Pod  Control  Computer 


Instruction  Set 

Size 

Weight 

Power 

Throughput 

Memory 


Input/Output 


Reliability 


MIL-STD-1750A;  MIL-STD-1589B  HOL 
5.0  x  7.1  x  13.1  inches 
17.9  pounds 
271  watts 

666  KOPS  (DAIS  instruction  mix) 

Nonvolatile  program  (65,536  words) 

Volatile  RAM  (65,536  words) 

Power-transient  protected  RAM  (1,024  words) 

Electrically  alterable  ROM  (1 ,024  words) 

Word  size  16  bits  plus  parity 
Discretes  (25  input;  32  output) 

Parallel  bus  (DMA:  880k  words/s;  Program  I/O:  200k  words/s) 
MIL-STD-1553B  data  bus  (remote  terminal) 

2,400  hours  (projected)  mean  time  between  failures 


Figure  1.  MIL-STD-1750A  Program  Characteristics 
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into  microprogram  starting  addresses. 
All  16  bits  of  an  instruction,  or 
multiple  words  of  multiword  instruc¬ 
tion  ,  can  be  mapped  into  microprogram 
addresses.  The  sequencing  and  control 
section  provides  the  address  linkage 
between  microinstructions,  and  it 
controls  the  CPU  processing  elements. 

Memory  System 

Two  types  of  memory  systems  are  cur¬ 
rently  in  use  on  Delco's  M372  compu¬ 
ter  family.  The  F-16  Enhanced  Fire 
Control  Computer  uses  a  core  memory, 
while  the  LANTIRN  Pod  Control  Compu¬ 
ter  is  a  combination  of  several  semi¬ 
conductor  technologies.  Either  option 
is  compatible  with  the  CPU  organiza¬ 
tion  previously  described . 

Semiconductor  Memory.  The  semicondu¬ 
ctor  memory  is  implemented  with 
devices  of  several  technologies,  pro¬ 
vides  64k  words  of  storage,  and 
features  nonvolatility  and  reprogram¬ 
mability,  coupled  with  fast  system 
level  access/cycle  times  for  high 
memory  bandwldths.  This  system  incor¬ 
porates  64k  words  of  high  speed  NMOS 
RAM,  backed  up  by  64k  words  of  UV 
EPROM,  2k  words  of  EE  PROM ,  and  Ik 
words  of  CMOS  RAM  (See  Figure  3.) 

In  operation,  the  memory  subsystem 
user' s  interface  with  the  NMOS  RAM 
allows  for  fast  access  (375  nano¬ 
second  system  level  access  times)  to 
instruction  and  operand  data.  The 
operand  write  data  address  to  the 
EEPROM-backed-up  section  of  memory  is 
written  into  the  NMOS  RAM  and  is 
transferred  to  the  EEPROM.  Write 
operations  to  the  CMOS  RAM  follow  a 
similar  path.  During  power  turnon, 
the  contents  of  the  UV  EPROM,  EEPROM, 
and  CMOS  RAM  backup  memories  are 
loaded  into  the  NMOS  RAM. 

Write  operations  into  NMOS  RAM, 
EEPROM,  or  CMOS  RAM  exhibit  cycle 
times  of  375  nanoseconds.  Writing 
into  the  CMOS  RAM  utilizes  a  pipe¬ 
lined  address/data  transfer  that 


65,535 

SHORT  TERM 

Ik 

TRANSIENT 

PROTECTED 

64,512 

LONG  TERM 

64.511 

2k 

PROTECTED 

63.488 

63,487 

PARAMETERS 

62,464 

62,463 

PROGRAM 

61k 

AND 

UNPROTECTED 

<^> 

SCRATCHPAD 

Address 

tk  CMOS 

•  Transient  Protec¬ 
ted  for  0.5-Second 
Interruption 

•  T  ransparent  to 
Software 

a  Capacitor  Backup 

2k  EEPROM 

•  Nonvolatile 
a  Electrically  Repro-| 
grammed  in  Com¬ 
puter 

e  Write  Endurance 
Limitation 

84k  UV  EPROM 

a  Nonvolatile 
a  High  Oensity 
a  Erasable  (Board 
Removed) 
a  Programmed  in 
Computer  Using 
Support  Equip¬ 
ment 


MAIN  MEMORY  (64k)  BACKUP  MEMORY  (64k) 


a  Random  Accan  a  Autoload  at  Turn-on 

a  Read  and  Write 
a  High  Speed 
a  Volatile 
a  NMOS 

Figure  3.  Semiconductor  Memory  Map 


allows  maintenance  of  consecutive 
write  operations  at  the  375-nano¬ 
second  rate.  The  EEPROM  write 
operations  require  20  milliseconds 
per  write,  which  limits  the  rate  of 
consecutive  write  operations  to  this 
area  of  memory.  A  discrete  input  bit 
is  made  available  to  the  software, 
indicating  when  the  EEPROM  has  com¬ 
pleted  its  write  cycle.  By  proper 
utilization  of  this  interlock  fea¬ 
ture,  the  available  memory  bandwidth 
of  2.667  million  16-bit  words  per 
second  is  maintained . 

Any  area  within  memory  address  space 
can  be  utilized  for  variable  storage, 
but  only  those  sections  backed  up  by 
CMOS  RAM  or  EEPROM  are  power- inter¬ 
ruption  protected  or  nonvolatile- 
memory  protected.  The  size  of  the 
EEPROM-backed-up  address  space  can  be 
varied  to  suit  the  system 
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requirements  from  0  to  256,  to  512, 
to  1,024,  or  to  2,048  words.  This  is 
accomplished  by  programming  the  memo¬ 
ry  module  connector  whereby  a  section 
that  is  deselected  from  EEPROM  backup 
becomes  backed  up  by  UV  EPROM.  The 
CMOS  RAM  protected  area  can  also  be 
deselected  by  connector  programming 
to  allow  this  section  of  memory  to  be 
backed  up  to  the  UV  EPROM. 

Programming  of  the  UV  EPROM  is 
accomplished  by  means  of  a  computer 
support  equipment  interface  with  the 
memory  subsystem  installed  in  the 
computer  enclosure.  The  NMOS  RAM  is 
loadable  from  the  support  equipment 
independently  of  the  UV  EPROM,  pro¬ 
viding  an  easily  alterable  memory  for 
software  development  activities. 

Core  Memory.  The  basic  core  memory 
system  is  64k  words  by  18  bits,  in¬ 
cluding  parity  and  a  storage-protec¬ 
tion  bit.  The  memory  system  consists 
of  two  32k-word  Memory  Magnetics 
Assemblies  (MMA)  ,  with  a  Memory 
Electronics  Interface  (MEI)  circuit 
card  assembly  to  facilitate  memory 
interleaving.  The  interleaved  monory 
bus  architecture  maximizes  memory 
subsystem  throughput  while  minimizing 
components  and  power  consumption. 
Features  of  this  architecture  are : 

•  Optimized  cost/ performance  ratio 

•  Advantageous  use  of  synchronisms 
between  memory  bus  subscribers 
while  operating  asynchronously 

•  Mo  boundary  restrictions  on 
operand  or  instruction  storage 

•  Worst  case  access  time  of  1.5 
microseconds  with  maximum 
contention 

•  Memory  bus  system  access  time  of 
562  nanoseconds  for  single  words 
and  937  nanoseconds  for  word  pairs 

e  Read,  write,  and  read-modify-write 
memory  modes . 


CORE  MEMORY  MODULE  CHARACTERISTICS 


ITEM 

DESCRIPTION 

ORGANIZATION 

2-1 /2D,  coincident  cur¬ 
rent,  wide  temperature 
range,  low  drive  cur¬ 
rent,  13-mil  0D  cores 

WORD  SIZE 

18  bits 

CAPACITY 

32,768  words  per  mod¬ 
ule,  expandable  to 
131,072  words 

CYCLE  TIME 

0.75  microsecond 

ACCESS  TIME 

0.375  microsecond  read; 
0.937  microsecond  write 

POWER 

MEI  =  14.7  watts; 

32k  MMA  =  32.5  watts 

SIZE 

4.3  x  6.4  x  3.0  inches 
(MEI  plus  MMA) 

WEIGHT 

3.5  pounds  (MEI  plus 
MMA) 

The  memory  system  is  supplemented 
with  a  memory  logic  (ML)  circuit  card 
assembly,  which  provides  basic  inter¬ 
nal  processor  bus  control.  Each  core 
memory  module  exhibits  access  times 
of  375  nanoseconds  and  cycle  times  of 
750  nanoseconds.  By  combining  these 
into  an  interleaved  memory  system,  an 
effective  cycle  time  of  375  nano¬ 
seconds  is  achieved.  The  ML  circuit 
also  contains  the  memory  write 
protect  logic. 

Word-by-word  memory  write  protection 
is  implemented  by  employing  the 
optional  18th  memory  bit  as  a  write- 
protect  bit  and  using  this  bit  for 
control  in  conjunction  with  the  read- 
modify-write  feature  of  the  memory. 
This  technique  results  in  a  one- 
clock-extended  memory  write  cycle 
when  compared  to  block  protection 
techniques.  Attempts  to  write  into 
protected  memory  result  in  setting 
the  appropriate  fault  register  bits. 


Direct  memory  access  (DMA)  users  are 
buffered  from  the  memory  interface 
bus  through  the  Input/Output  Con¬ 
troller  (IOC)  .  Consequently,  memory 
bus  loading  is  minimized,  and  the 
processor  and  memory  subsystem  can 
run  at  the  fastest  possible  speed. 
Incorporation  of  the  IOC  also  allows 
DMA  users  to  enjoy  a  shared  data  and 
address  I/O  bus,  merged  from  the 
memory  address  and  data  buses,  and 
provides  simpler  control  by  the  IOC. 
As  a  result,  the  computer  memory 
interface  and  I/O  bus  system  provide 
a  carefully  chosen  and  optimized 
blend  of  performance  and  efficiency. 


Bubble  Memory.  Delco  Electronics  has 
recently  completed  the  design  of  a 
bubble  memory  system.  This  type  of 
raonory  system  has  been  selected  by 
the  McDonnell  Douglas  Aircraft  Comp¬ 
any  for  use  in  Delco' s  Flight 
Management  Systems  being  supplied  for 
versions  of  the  DC-10  and  DC-9  air¬ 
craft.  System  testing  of  bubble 
memory  systems  for  the  preproduction 
computers  ha3  recently  been  com¬ 
pleted  .  These  tests  included  opera¬ 
tion  over  £he  temperature  range  of 
-40  to  +85  C.  This  memory  type  is 
also  available  for  M372  computers. 


Input/Output  Subsystem 


A  versatile  and  efficient  input/out¬ 
put  subsystem  is  a  core  element  of 
the  computer.  An  Input/ Output  Con¬ 
troller  (IOC)  services  the  interrupt 
processor,  the  various  digital  input/ 
output  channels  and  discretes,  the 
multiplex  buses,  and  the  external 
support  equipment  port.  The  IOC 
interfaces  both  the  memory  interface 
(MI)  and  the  programmed  I/O  (PIO) 
buses  with  the  I/O  bus.  The  Input/ 
Output  Controller  supports  direct 
memory  access  (DMA)  ,  programmed  I/O, 
interrupt  I/O,  and  the  instruction 
insert  operations.  The  I/O  bus  con¬ 
sists  of  a  parallel,  bidirectional, 
shared  data  and  address  bus  with  con¬ 
trol  signals  dedicated  to  each  of  the 


above  operations.  General  purpose 
functions  provided  by  the  I/O  system 
include  the  following: 

•  Sixteen  levels  of  vectored, 
prioritized  interrupts 

•  Two  programmable  16-bit  interval 
timers 

•  Time-out  or  watchdog  timer 

•  Decode  of  I/O  device  addresses  and 
function  codes  ( microprogram  out¬ 
puts  from  CPU) 

•  Interface  with  3ignal  conditioner 
modules. 

MIL-STD-1553B  Data  Bus.  Delco' s  new 
multi-bus  system  allows  two  or  more 
MIL-STD-1553B  multiplex  bus  channels 
to  be  used  in  an  avionics  suite  with 
minimum  hardware  penalties.  Bus  sys¬ 
tems  can  be  dedicated  to  functions 
such  as  display  or  flight  control, 
with  a  passthrough  feature  provided 
to  transfer  data  from  one  bus  system 
to  another.  The  bus  control  system 
allows  the  computer  to  simultaneously 
operate  as  a  bus  controller  or  remote 
terminal  on  single  or  multiple 
independent  multiplex  data  bus 
systems.  Each  bus  channel  consists  of 
a  dual  redundant  serial  data  inter¬ 
face  capable  of  communicating  con¬ 
currently  with  subsystems  operating 
under  MIL-STD-1 553 ,  1553A,  and/or 

155 3B  protocols. 

Two  dual-redundant  channels  are  pre¬ 
sently  provided  on  three  1/2-ATR  cir¬ 
cuit  card  assemblies,  j  3ingle  Data 
Bus  Controller  (DBC)  for  each  channel 
and  a  shared  transmitter/receiver 
module,  referred  to  as  the  Data  Bus 
Interface  (DBI).  The  controllers 
interface  via  the  I/O  bus  to  the 
Li  put/ Output  Controller  (IOC)  ,  which 
contains  circuitry  necessary  to 
interface  the  DBC  channels  to  the 
programmed  I/O  and  DMA  functions  of 
the  processor . 
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The  DBC  controls  the  operation  of  the 
multiplex  bus,  each  channel  operating 
independently  so  that  the  multiplex 
bus  interface  operates  simultaneous¬ 
ly,  requiring  little  intervention 
from  the  CPU.  The  DBC  receives  con¬ 
trol  commands  and  address  information 
from  the  CPU  through  the  programed 
I/O  via  the  IOC,  which  initiates  the 
execution  of  a  microprogrammed 
algorithm  to  operate  in  a  given  mode 
by  sequentially  accessing  commands 
and/or  data  from  the  manor y  via  DMA. 

Data  flow  between  the  DBC  and  IOC  is 
word  by  word,  controlled  by  "hand¬ 
shaking"  signals  provided  by  the  DBC 
for  multiplex  bus  transactions  (DMA 
instructions  and  data)  and  by  the 
processor  for  DBC  control  and  status 
( programmed  I/O) .  The  DBC  tests  all 
multiplex  bus  transactions  for  inval¬ 
id  sync.  Invalid  biphase  Manchester 
code,  incorrect  bit  count  (total 
transmission  time) ,  and  parity  error 
and  indicates  errors  to  the  IOC. 

Operator  or  software  activation  of 
the  MIL -STD-1 553  system  has  been 
minimized  to  assure  proper  sequencing 
without  significant  programmer 
Involvement . 


Additional  I/O  Functions.  Depending 
on  the  application,  various  addi¬ 
tional  I/O  functions  are  provided.  Ih 
the  F-16  Fire  Control  Computer  appli¬ 
cation,  two  additional  circuit  card 
assemblies  are  provided ,  a  Digital 
I/O  (DIO)  and  an  A/D  Converter  ( ADC) . 
The  Digital  I/O  Includes  6  differen¬ 
tial  input,  8  differential  output, 
and  12  high  level  input  discretes 
along  with  the  real  time  clock  and 
COP  circuitry  (real  time  program  loop 
error  detection) .  The  12-bit  A/D  Con¬ 
verter  accepts  six  dc  analog  inputs 
and  two  three-wire  synchro  inputs. 

The  LANTIRN  Pod  Control  Computer  has 
a  Discrete/Interrupt  Timer  (DIT)  cir¬ 
cuit  card  assembly  that  includes  16 
input  and  16  output  external  differ¬ 


ential  discretes,  9  input  and  16  out¬ 
put  internal  discretes,  6  external 
interrupts,  progranmable  timers  per 
M IL -STD-1 750A ,  and  COP  circuitry. 

Power  Supply 

The  F-16  Fire  Control  Computer  power 
converter  is  composed  of  an  ac/dc 
converter  and  a  dc/de  converter.  This 
mechanization  combines  the  reliabi¬ 
lity  of  a  low  risk,  well  proven 
design  with  high  efficiency,  low 
cost,  and  minimum  size.  The  converter 
employs  400-hertz,  three-phase,  115- 
volt  rms  primary  power  and  provides 
all  necessary  system  operating  volt¬ 
ages.  The  converter  will  shut  down 
and  not  be  damaged  if  one  or  more 
phases  of  the  source  voltage  is  miss¬ 
ing  or  degraded.  The  converter  also 
provides  modlng  for  turn-on  and  turn¬ 
off  sequencing.  The  power  converter 
exhibits  the  following  features: 

e  Operates  from  a  400-hertz,  three- 
phase,  115-volt  rms  source  and 
meets  the  requirements  of  MIL-STD- 
704  and  MIL-STD-461 ,  including  the 
emergency  condition  requirements 
of  MIL -STD-704 

e  Turn-on  so ft- start  prevents  input 
surge  currents 

e  Programmed  turn-off  and  restart 
for  power  interruptions 

e  Self-contained  overvoltage  pro¬ 
tection 

e  Input  protection  for  high  voltage 
transients 

e  Internal  high  energy  transient 
generation  reduced  by  controlled 
turn-on  and  virtual  elimination  of 
simultaneous  conduction  of  power 
transistor  pairs 

e  Maximized  reliability  from  use  of 
switching  transistors  with  high 
reverse  energy  rating  and  liberal 
power  derating  of  semiconductors. 
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A  memory  protect  moding  section  pro¬ 
vides  the  delays  and  timing  necessary 
to  assure  the  orderly  turn-on  and 
turn-off  of  memory.  It  allows  data  to 
be  maintained  in  core  through  a  power 
interruption.  This  section  includes  a 
level  detector,  memory  turn-on  delay, 
in put/ output  isolator ,  and  the  memory 
protect  logic.  The  input  level  detec¬ 
tor  also  provides  for  dc/dc  converter 
turn-on  and  shutdown  at  a  predeter¬ 
mined  level  of  the  input  to  aid  in 
the  moding  function . 

Output  voltage  regulation  is  +5  per¬ 
cent  (except  for  the  10-volt  core 
memory  voltage,  which  is  +1  percent)  . 
A  regulation  of  *2  percent  is 
achieved  considering  line  variations 
and  temperature  of  operation.  When 
considering  load  variations,  ±5 
percent  regulation  is  standard  on  all 
Delco  Electronics  computer  power 
supplies . 

The  LANTIRN  Pod  Control  Computer 
receives  its  voltages  from  an 
external  source. 


Mechanical  Desif 


The  MIL-STD-1 750A  F-16  Fire  Control 
Computer  is  package^  in  a  1/2 -ATR 
enclosure.  Its  fully  modularized 
design  and  construction  is  similar  to 
that  of  Delco* s  M362  series  computers 
(including  the  original  F-16  Fire 
Control  Computer,  Inertial  Upper 
Stage  Guidance  Computer,  and  the  Air¬ 
borne  Instrumentation  Labs  computers) 
and  the  highly  reliable  Magic  III 
computers  of  which  more  than  7,000 
have  been  produced. 


In  the  F-16  configuration,  the  enclo¬ 
sure  design  employs  a  bolted  and 
bonded  assembly  technique  first  used 
by  Delco  on  the  Apollo  program  to 
form  a  tight,  light  weight,  low  cost, 
rigid  assembly.  The  top  and  bottom  of 
the  enclosure  contain  heat  exchangers 
to  which  the  computer  circuit  card 
assemblies  are  thermally  coupled. 


A  top  cover  allows  access  to  the  cir¬ 
cuit  card  assemblies  for  maintenance. 
The  unit  contains  plug-in  circuit 
card  assemblies  plus  a  connec tori  zed 
power  supply.  Delco-designed  circuit 
card  guides  (heat  transfer  clips)  are 
used  for  mounting  circuit  cards  in 
the  enclosure.  Flatpack  devices  pro¬ 
vide  high  density  functional  packag¬ 
ing  .  Each  circuit  card  contains  a 
center  core  for  conducting  the  heat 
from  circuit  devices  to  the  card 
edges.  Strain  relief  is  inherent  in 
the  flatpack  mounting  scheme.  The 
1/2-ATR  card  size  is  optimum  for  the 
thermal  and  vibration  environments 
encountered . 

The  circuit  card  assemblies  are 
plugged  into  a  multilayer  intercon¬ 
nect  board  using  metal- shell ,  two- 
piece  ,  pin/  socket,  twist-pin, 
gold-plated  connectors.  The  packaging 
is  simple,  reliable,  and  eliminates 
adverse  heat  density  conditions.  The 
power  conditioner  structure  is  fabri¬ 
cated  from  plate  stock  and  is  screwed 
together  with  a  sheet  metal  cover , 
providing  an  011-tight  assembly.  All 
surfaces  are  coated  to  prevent 
corrosion . 

Because  of  the  packaging  flexibility 
available  through  the  use  of  1/2-ATR 
modules,  Delco  has  been  able  to 
accommodate  unusual  form  factor 
requirements  with  no  sacrifice  in 
performance  in  a  wide  variety  of 
applications,  as  in  the  case  of  the 
LANTIRN  Bod  Control  Computer  where 
coldplate  cooling  and  extremely  tight 
packaging  constraints  imposed  by  the 
LANTIRN  pod  size  and  form  factor 
resulted  in  the  configuration  shown 
in  Figure  1. 


User's  Control  Consol.  The  M372 
User's  Control  Console  (UCC)  provides 
the  capability  for  computer  hardware 
maintenance ,  operational  software 
development  and  debug,  and  system 


integration  support.  Consisting 
entirely  of  commercial  equipment,  and 
based  on  the  Computer  Automation , 
Incorporated,  LSI-4  minicomputer,  it 
includes  the  following  items: 

•  6 4k -word  semiconductor  RAM 

•  Distributed  I/O  system  with 
intelligent  cables 

•  Dual  floppy  disk  subsystem  with 
486k  bytes  of  storage 

•  CRT/ keyboard 

e  30-character- per- second  printer 

•  Autoload  ROM 

•  High  speed  controller-processor 
interface . 

The  UCC  is  packaged  in  a  small ,  up¬ 
right  cabinet  on  casters,  has  a  self- 
contained  power  supply,  and  is 
sufficiently  portable  for  use  in 
highly  remote  field  locations.  A  com¬ 
plete  software  package  is  provided, 
including  a  user-oriented  operating 
system,  symbolic  debug  package,  and 
maintenance  programs.  The  UCC  pro¬ 
vides  complete  control  of  the  compu¬ 
ter,  including: 

•  Stop ,  halt ,  run ,  and  reset 

•  Instruction  step  and  instruction 
insert/  execute 

•  DMA  read/write 

e  Real  time  interrupt  and  operator 
controlled  interrupt 

e  Parity  detect,  illegal  address 
protect,  and  stop  on  fault 

e  Match  on  operand  address,  DMA 
address ,  instruction  address ,  and 
DMA  data . 

By  adding  an  optional  I/O  exerciser, 
the  UCC  can  be  converted  into  a  full- 


up  tester.  The  I/O  exerciser  consists 
of  a  dual-redundant  multiplex  data 
bus  interface  and  digital  input/ 
output  electronics  capable  of  fully 
exercising  the  I/O  subsystem.  The  I/O 
exerciser  is  in  the  UCC  cabinet  and 
interconnected  to  the  computer 
through  operational  cable  interfaces. 

Software  Development  Station.  The 
Software  Development  Station  (SDS)  is 
an  extension  of  the  UCC  and  is  also 
built  around  a  Computer  Automation, 
Incorporated ,  LSI-4/90,  16-bit  mini¬ 
computer  with  a  6 4k -word  memory.  The 
SDS  is  supported  by  sufficient 
peripheral  equipment  and  software  to 
provide  a  sophisticated  standalone 
program  development  station  for  M372 
application  programs. 

The  software  to  support  the  facility 
includes  the  Delco  M372  assembler 
system  and  the  LSI-4  OS  operating 
system .  The  assembler  system  contains 
a  relocatable  assembler,  linkage  edi¬ 
tor,  and  cross  reference/ edit  rou¬ 
tines.  Outputs  include  absolute 
listings  after  link  with  extensive 
error  and  warning  message  support , 
memory  maps,  external  symbol  tables, 
global  and  module-level  cross  refer¬ 
ence  tables,  and  files  to  support  a 
symbolic  debug  capability.  Utility 
programs  provide  nine-track  magnetic 
tape  communication  between  the  SDS 
and  a  central  data  processing  faci¬ 
lity.  This  capability  allows  J73 
computer  object  modules  generated  by 
the  central  data  processing  facility 
to  be  linked  with  assembly  modules 
prepared  on  the  SDS. 

The  LSI-4  OS  operating  system  pro¬ 
vides  file  management,  LSI-4  program 
generation,  editor  programs,  and  Job 
control  to  support  M372  generation 
and  modification.  Utility  commands 
allow  the  user  to  assign  logical 
units,  execute  job  files,  and  manage 
disks.  The  user  may  generate  LSI-4 
programs  that  run  under  the  OS 
operating  system  and  use  OS  service 
routines . 
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Figure  4.  UCC/SDS  Block  Diagram 

SUPPORT  SOFTWARE  PROGRAMS 
PROGRAM  HOST 

SYMBOLIC  DEBUG  PACKAGE  LSI-4 

ACCEPTANCE  TEST  PROGRAM  M372/LSI-4 

•  Instruction  Exerciser 

•  Memory  Exerciser 

•  I/O  Controller 

•  Controller 

J73  COMPILER  (GFE)  IBM370 

•  M IL -STD-175  OA 

•  IBM370 

INTERPRETIVE  COMPUTER 
SIMULATION  (GFE)  DEC-10 

•  MIL-STD-1750A 

MIL-STD-1750A  ASSEMBLER 
SYSTEM  (OPTIONAL)  LSI-4 

•  Assembler 

e  Link  Editor 

•  Loader 


An  80-megabit  disk  provides  adequate 
storage  to  support  the  system  and  the 
user's  application  programs.  A  floppy 
disk  provides  a  convenient  means  to 
move  object  programs  for  loading  into 
the  M372  computer . 


M372  Computer  Support  Software 


Available  M372  computer  support  soft¬ 
ware  is  listed  below.  Government 
sponsored  development  is  currently 
underway  for  a  MIL-STD-1750A  simula¬ 
tor  and  a  J73  compiler  hosted  on  the 
DEC-10  computer. 


MAGIC  V  COMPUTER  (M572) 


The  Magic  V  computer  program  is  a 
logical  extension  of  Delco's  M372 
computer  development  activity.  Where¬ 
as  the  M372  is  designed  to  meet 
earl y-1 980  high  performance  avionics 
mission  computer  applications  (with 
updates,  as  necessary,  consistent 
with  new  requirements  and  available 
technology)  ,  the  Magic  V  computer  is 
targeted  for  the  mid-1980's  and 
beyond,  with  performance  goals 
matching  the  anticipated  requirements 
of  this  time  frame.  The  broad  out¬ 
lines  of  the  Magic  V  computer  began 
to  emerge  approximately  a  year  and  a 
half  ago  when  it  bee  an  e  evident  that 
the  key  to  meeting  the  next  genera¬ 
tion  computer  requirements  was  use  of 
VLSI  circuit  technology.  All  major 
computer  characteristics  —  weight, 
power,  speed,  size,  cost,  reliability 
—  have  the  potential  for  enhancement 
through  VLSI. 

Because  of  Delco's  commitment  to 
standards,  the  first  Magic  V  computer 
(M572)  will  implement  the  two  major 
hardware  standards,  MIL-STD-1750A 
instruction  set  architecture  and  MIL- 
STD-1553B  multiplex  bus.  In  addition 
to  these  standards,  a  baseline  set  of 
performance  goals  was  established, 
based  on  an  assessment  of  the 
requirements  of  the  mid-1980's.  The 
imposition  of  standards  and  the  per¬ 
formance  goals  listed  below  defined 


the  M572.  The  M572  is  intended  to  be 
a  total  computer  system,  including  a 
CPU,  memory,  I/O,  power  supply,  and 
structure .  Production  hardware  will 
be  available  in  1984,  and  a  higher 
performance  version  will  be  available 
approximately  a  year  later. 

The  overall  >672  program  objectives 
are  to: 

e  Implement  the  MIL-STD-1 750A 
instruction  set  architecture  with 
an  all-VLSI  solution . 

e  Select  a  technology  that  reduces 
power  consumption,  thereby  mini¬ 
mizing  concerns  over  cooling, 
packaging,  and  heat  dissipation. 

e  Minimize  the  technology  risk. 

e  Establish  a  reliable  manufacturing 
source,  with  Delco  controlling  the 
design  and  thus  guaranteeing  the 
future  availability  of  the  VLSI 
devices. 

e  Provide  the  hardware  on  a  schedule 
that  assures  a  timely  transition 
from  the  M372  and  its  upgraded 
versions  to  that  of  the  M572. 

Among  the  more  significant  specific 
M572  performance  objectives  are: 

e  Throughput  of  750  KOPS  in  1984  to 

1985,  increasing  to  1.6  KOPS  by 

1986. 

e  A  70-  to  30-percent  reduction  in 
recurring  cost  compared  with  a 
comparable  1981  time  frame. 

e  Reliability  of  at  least  40,000 
hours  MIBF. 

e  Power  consumption  of  less  than  20 
watts,  including  power  supply. 

e  Fault  Isolation  to  a  plug-in 
module,  with  coverage  approaching 
100  percent 


a  A  complete  computer  system, 
including  power  supply  and 
enclosure,  which  occupies  0.1 
cubic  foot  and  weighs  6  pounds. 

These  objectives  are  based  on  a  blend 
of  an  assessment  of  the  mid-1980's 
requirements  with  a  Judgement  as  to 
what  the  technology  will  allow.  If 
experience  is  any  Judge,  these  goals 
will  probably  be  exceeded. 

A  summary  of  the  characteristics  of 
the  M572  along  with  a  comparison  with 
the  current  technology  as  applied  to 
the  F-1 6  Ehhanced  Fire  Control  Compu¬ 
ter  is  presented  in  Table  1.  A  mockup 
of  an  M572  equivalent  to  the  F-1 6 
Fire  Control  Computer  is  also  shown. 

The  Magic  V  computer  is  being  devel¬ 
oped  on  company  funds  as  a  part  of 
Delco' s  Independent  Research  and 
Development  effort.  This  allows  Delco 
the  freedom  to  develop  the  computer 
in  strict  accordance  with  the  above 
objectives  on  a  schedule  consistent 
with  Delco' s  resources  and  realistic 
future  program  needs.  Another  factor 
in  this  decision  is  Delco' s  commit¬ 
ment  to  developing  computer  systems, 
rather  than  just  components,  to 
assure  an  optimized  solution  to  the 
needs  of  its  customers. 

The  development  of  a  custom  VLSI  com¬ 
puter  solution  by  Delco  has  several 
important  advantages  for  the  custo¬ 
mer,  the  most  significant  of  which  is 
the  guaranteed  availability  of  the 
VLSI  chips  for  as  long  as  required 
for  a  given  program.  This  is  possible 
because  Delco  will  own  the  masks  and 
have  a  guaranteed  source  of  process¬ 
ing.  Use  of  custom  devices  also 
reduces  the  nunber  of  part  types, 
thereby  simplifying  procurement  and 
sparing  and  reducing  life  cycle  cost. 

Delco  believes  that  the  Magic  V  pro¬ 
gram  and  schedule  are  low  risk,  rea¬ 
listic,  and  timely  and  address 
themselves  to  the  requirements  of  the 
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PARAMETER 


Incut/Output 


Row  Supply 


CURRENT  TECHNOLOGY  MAGIC  V  OBJECTIVES 

M372  F-1E  FIRE  CONTROL  I  Compared  widl  F16  Requirements) 


5.4  by  7.8  by  16  inches;  31  pounds;  4.1  by  5.3  by  8.7  inches;  6.0  pounda: 
043  cubic  foot  0.11  cubic  feat. 


587  KOPS  (core  Mamory);  668  KOPS  >  750  HOPS  (19841 
(sarmoonductor  mamoryl.  1.800  KOPS  (1988) 


40,000  houn. 


$0.3  to  0.3P  par  system. 


MIL  ST0-1750A  ISA 


64k  by  10-bit  plus  atror  dataction  and 
correction  main  mamory  (singla  CCA). 


Nonvoiatila  main  mamory  backup. 
Avai lab ia  options  include:  battary, 
EEPROM,  and  Bubble. 


•  Two  channel*,  dual- redundant  MIL-  I  •  Single  chip  MIL-STD-1563B  bus 


1.900  houn. 


SP  par  system. 


MIL-STD-17SQA  ISA. 


Two  32k  by  18  bin  core  modules. 


STD-15538  (1  CCA/cbannai) 


a  Analog  (dc  and  aynchrel 
a  Direct  Mamory  Aocaai  (DMAI. 


8.0  pounda;  210  wara  output;  and 
>  70  pareant  afficiancy. 


a  Singla  chip  atandard  I/O  (sarial,  p 
alU.  discretas,  DMA.  RS-232  . . . 
react  complainant  -  TBD). 


0.7  pound;  20  to  30  wans  output; 
75  pareant  afficiancy. 


TECHNOLOGY 

Packaging 


a  Integrated  circuits  in  flatpaeka  a  Custom  VLSI  chips  in  ieedlaas  Chio 
a  Conventional  double  and  multllayar  earners  (LCC'tl 

circuit  boards  a  LCC'i  on  ceramic  modulaa  IMAM'S) 

a  Forced  air  cooling  with  hast  re-  mounted  on  pnntsd  circuit  cards,  or 

changers.  LCC'i  on  metal  core  circuit  cards 


fault  Management 


Standard  MSI  and  SSI  chips. 


a  Setf-tast  fault  isolation  to  a  single 
replaceable  module  (LRU) 
a  Coverage  —  95%. 


a  Custom  VLSI  circuits 
a  Three  micron  bulk  CMOS. 


a  Salt-test  fault  isolation  to  a  t 
replaceable  module  (LRUI 
a  Casa  rage  approaching  100*. 


Table  1.  H572  Computer  Characteristics 


high  performance  avionics  and  space 
computer  markets  of  the  next  decade. 

CONCLUSION 

Delco  Electronics  supported  the  Air 
Force  move  to  a  standard  architecture 
relatively  soon  after  the  idea  was 
introduced,  but  not  without  some 
indecision  in-house.  In  fact,  the 
acceptance  and  implementation  of 
these  standards  forced  a  costly 
change  in  development  plans  within 
Delco  Electronics.  This  early  deci¬ 
sion  to  produce  MIL-STD-1750A  compu¬ 
ters  allowed  Delco  to  capture  the 
first  two  MIL-STD-175 OA  Air  Force 
production  programs  —  LANTIRN  and 
F-16  MSIP. 

Standardization  at  the  ISA  level 
allows  introduction  of  new  devices 
that  lead  to  new  computer  systems 


that  are  faster,  smaller,  lighter, 
and  consume  less  power.  The  M572,  to 
be  introduced  in  1984  as  a  result  of 
active,  current  IRAD  effort,  will  be 
a  MIL-STD-1750A  machine.  This  machine 
may  then  be  followed  by  the  M582 
executing  the  MIL-STD-1862,  NEBULA 
architecture . 

There  is  a  complementary  requirement, 
however,  that  the  Military  control 
the  new  standards  properly.  With  the 
proper  control  of  standards  from  the 
Department  of  Defense  and  with  devel¬ 
opment  from  the  private  sector,  these 
standards  could  become  a  valuable 
asset . 

Delco  Electronics  believes  in  the 
concept,  and,  if  the  concept  is  main¬ 
tained,  Delco  Electronics  may  be 
manufacturing  only  Military  standard 
computers  5  years  from  now. 
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A  NEW  SILICON-ON-SAPPHIRE  MIL-STD-1750A  MICROPROCESSOR 
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Gregory  Portanova,  Steven  Nicholas, 

John  Riordan,  Richard  Meeks troth 

Mikros  Systems  Corporation 
Mercerville,  New  Jersey 


ABSTRACT 

This  paper  describes  the  MKS1750,  a  new  implementation  of 
the  United  States  Air  Force  MIL-STD-1750A  architecture  fabri¬ 
cated  entirely  in  SOS/CMOS  technology.  The  MKS1750  is  a  chip 
set  based  on  a  proprietary  microprogrammable  16-bit  micropro¬ 
cessor  (the  MKS16 )  supported  by  additional  logic  implemented 
as  semi-custom  gate  arrays  and  ROMs  for  control  store.  A 
total  of  eleven  chips  is  required.  Power  consumption  of  the 
MKS1750  is  less  than  lw  and  throughput  is  greater  than  200  KIPS, 
measured  using  the  USAF  DAIS  mix. 

A  complete  description  of  the  chip  set  is  given,  including 
the  architecture  of  the  MKS16,  gate  array  partitioning  and  the 
functional  specification  of  each  array.  The  paper  also  discusses 
the  structure  of  the  MKS1750  microprogram,  available  software 
support  and  packaging  considerations. 

1.  INTRODUCTION 

The  advantages  of  SOS/CMOS  technology  in  computer  applica¬ 
tions  are  well  known:  high  speed,  low  power  consumption,  high 
packaging  density,  and  radiation  resistance.  While  the  cost  of 
the  sapphire  substrate  precludes  its  use  in  high-volume  commer¬ 
cial  applications,  the  aforementioned  attributes  of  SOS /CMOS  are 
overwhelmingly  important  (and  in  some  cases,  imperative)  in 
military  computers  (1,2). 

The  Mikros  strategy  has  been  to  use  SOS/CMOS  for  the  design 
and  development  of  a  full  16-bit  CPU  chip.  Additionally,  the 
basic  CPU  is  microprogrammable  using  external  control  store  to 
allow  emulation  of  a  variety  of  instruction  set  architectures. 

This  paper  describes  the  emulation  of  the  USAF  MIL-STD-1750A 
architecture  using  the  Mikros  MKS16  processor  chip  supported  by 


SOS/CMOS  gate  arrays  and  control  store.  The  chip  set  executes 
the  full  1750A  instruction  set  (including  floating-point)  at 
a  throughput  of  265  KIPS  (DAIS  instruction  mix)  and  dissipates 
less  than  1  Watt. 

2.  MKS1750  ARCHITECTURE 

2.1  OVERVIEW 

The  MKS1750  is  a  microprogrammed  processor  which  executes 
the  USAF  MIL-STD-1750A  instruction  set  (3) .  It  has  the  following 
features : 

o  MULTIBUS™-compatible  interface  (4) 
o  16-bit  microprograramable  processor 
o  Eleven  chip  LSI  implementation 

The  architecture  of  the  MKS1750  is  based  on  a  16-bit  inter¬ 
nal  bus  (the  I-bus,  see  Fig.  1).  Sequential  execution  of  1750A 
instructions  is  controlled  by  the  MKS16  processor,  which  is 
responsible  for  instruction  fetch  and  decode,  effective  address 
calculations,  operand  fetch  and  store,  and  arithmetic  operations. 
External  logic  is  provided  to  support  1.750 A.  emulation  in  the 
following  areas: 

o  additional  microsequencing  features 
o  MULTIBUS™  interface 
o  175 0A  interrupts  and  faults 

o  additional  register  file  and  addressing  logic 

The  control  ROM  (2Kx48)  provides  synchronous  control  signal  t> 
both  the  external  logic  and  the  MKS16. 

2.2  THE  MKS16  MICROPROGRAMMABLE  PROCESSOR 

The  MKS16  has  a  register  file/ALU/sequencer  architecture 
with  internal  status,  instruction  and  shift  registers  (see  Fig. 

2)  (5) .  The  processor  communicates  with  a  bidirectional  data 

bus  through  two  multiplexers  (IBX,  OBX) .  Internal  storage  is 
provided  by  the  scratchpad  (SPAD) ,  a  16x16  register  file.  The 
A  and  X  registers  (AR,XR)  are  used  as  accumulators  and  for  shift 
operations.  The  status  register  (SR)  contains  condition  codes 
and  status  flags.  The  16-bit  parallel  ALU  provides  two's-com- 
plement  arithmetic  and  boolean  operations.  The  architecture 
supports  a  limited  degree  of  parallelism  at  the  micro-operation 
level. 

The  MKS16  is  driven  by  a  27-bit  microinstruction  word.  The 
microinstruction  is  time-multiplexed  into  PRIMARY  and  SECONDARY 
words  which  are  fetched  sequentially  from  control  store  during 
one  microcycle.  The  format  of  the  standard  microinstruction 
word  is  shown  in  Fig.  3.  In  this  case,  bits  C15-17,  C31,  C32 
are  not  used  by  the  MKS16  and  may  be  used  as  control  bits  for 
external  logic. 


MKS1750  Functional  Diagram 


The  MKS16  microsequencer  does  not  use  a  default  flow-of- 
control  convention;  each  microinstruction  specifies  the  next 
microaddress,  explicitly.  The  low-order  four  bits  of  the  address 
(the  WORD  ADDRESS)  are  given  by  C27-C30.  The  high-order  four 
bits  (the  PAGE  ADDRESS)  are  determined  by  a  LINK  MODE  specifying 
the  source  of  the  page  address.  The  sequencer  allows  conditional 
branching  based  on  the  condition  codes. 

The  MKS16  requires  three  clock  signals,  and  can  run  at 
either  TTL  or  CMOS  levels.  The  maximum  clock  rate  is  5.5  MHz, 
giving  a  microcycle  time  of  180  nsec. 

2.3  REGISTER  STRUCTURE 

The  MKS1750  uses  an  external  16x16  register  file  to  provide 
the  1750A  registers.  The  MKS1750  contains  dedicated  logic  to 
support  register  concatenation  and  register  addressing  using 
macroinstruction  fields.  This  logic  uses  the  external  instruc¬ 
tion  register  (XIR) ,  which  is  loaded  with  a  1750A  instruction 
during  the  fetch  cycle.  The  XIR  S  and  D  fields  are  used  by 
most  1750A  instructions  as  register  addresses,  and  may  be  used 
directly  to  access  the  specified  register.  Alternatively,  a 
literal  4-bit  address  may  be  specified  directly  by  the  micro¬ 
instruction  word.  The  S  and  D  fields  are  implemented  as  four- 
bit  up/down  counters,  to  provide  access  to  adjacent  registers 
as  required  by  1750A  multiple-precision  instructions.  The  S 
and  D  fields  may  also  be  concatenated  to  form  an  eight-bit 
up/down  counter.  Zero-detect  logic  is  provided  for  all  three 
counters.  This  logic  is  used  extensively  in  implementing 
indexed  addressing  and  shift  instructions. 

2.4  THE  MKS1750  MICROSEQUENCER 

The  MKS16  internal  sequencer  is  oriented  towards  instruction 
decoding.  Typically,  four  bits  of  the  instruction  register  (IR) 
are  used  as  the  page  address,  providing  a  sixteen-way  branch  in 
control  store.  The  MKS1750  microsequencer  provides  logic  for 
expanded  nicroaddress  space,  microsubroutining,  instruction 
decoding  and  testing  of  external  conditions. 

Three  extra  microaddress  bits  are  taken  directly  from  the 
microinstruction  word,  and  are  appended  to  the  MKSl6-generated 
address  as  the  high-order  bits.  The  resulting  11-bit  address 
is  known  as  the  NORMAL  ADDRESS  (N-address)  and  is  one  of  four 
inputs  to  the  NEXT  ADDRESS  MULTIPLEXER  in  the  microsequencer 
(see  Fig.  4) .  Another  input  is  the  LONG  ADDRESS  (L-address) 
which  is  a  literal  11-bit  address  specified  in  the  microinstruc¬ 
tion.  The  next  address  may  also  be  obtained  from  the  return 
address  stack  (3x11) .  The  final  address  mux  input  is  obtained 
by  concatenating  the  three  high-order  extension  bits  with  an 
8-bit  value  from  the  I-bus. 


N-addressing  is  required  for  a  microsuferoutine  call  oper¬ 
ation.  In  this  case,  the  return  address  is  not  specified 
explicitly  by  the  microinstruction,  but  is  determined  by  in¬ 
crementing  the  high-order  three  bits  of  the  current  micro¬ 
address.  N-addressing  is  also  required  by  microinstructions 
which  test  internal  or  external  conditions. 

The  MKS16  internal  link  modes  may  also  be  combined  with 
the  external  modes  to  provide  extra  sequencing  features.  The 
microsequencer  also  allows  the  execution  of  an  instruction  to 
be  aborted  if  certain  machine  faults  occur  during  execution. 

2.5  THE  BUS  INTERFACE 

The  MKS1750  is  logically  compatible  with  the  MULTIBUS* 
standard.  Address,  data,  command,  and  status  signals  are 
supported. 

The  20  address  lines  are  TTL-compatible  signals  which  pro¬ 
vide  1  Mword  of  physical  address  space.  The  16  bidirectional 
data  lines  are  TTL-compatible  signals  which  provide  a  16-bit 
data  bus.  To  communicate  with  slave  devices,  several  control 
signals  are  provided:  memory  read/write  (MRDC,  MWTC)  and  I/O 
read/write  (IORC,  IOWC) .  Slave  devices  acknowledge  transfers 
using  the  XACK  control  line. 

A  multi-master  environment  is  supported  using  serial  prior¬ 
ity  arbitration.  BREQ  and  BUSY  are  polled  by  each  requesting 
device  to  determine  whether  a  bus  access  may  occur. 

There  are  8  user-defined  interrupt  signals  which  are  pro¬ 
cessed  by  the  interrupt  controller.  A  bus  transfer  example  is 
shown  in  Fig.  8. 

2.6  INTERRUPTS  AND  FAULTS 

The  MKS1750  contains  three  registers  dedicated  to  the  1750A 
pending  interrupt  (PI) ,  interrupt  mask  (MK) ,  and  fault  (FT) 
registers.  The  hardware  determines  from  the  values  of  PI  and  MK 
if  there  is  a  valid  interrupt  which  requires  service  by  the  MKS16 
If  so,  this  logic  asserts  the  MKS16  interrupt  request  line,  and 
this  in  turn  is  detected  by  the  MKS16  sequencer.  The  MKS1750 
normally  tests  for  the  presence  of  a  valid  interrupt  at  the  end 
of  each  instruction.  If  one  is  detected,  the  processor  deter-  • 
mines  its  priority  by  reading  PI  and  MK,  calculates  the  address 
of  the  new  context,  and  performs  the  context-switch  operation. 
Certain  1750A  interrupts  (executive  call  and  arithmetic  excep¬ 
tions)  are  not  asynchronous  events  as  they  occur  only  as  the 
result  of  instruction  execution.  In  these  cases  the  micropro¬ 
gram  must  set  the  correct  PI  bit. 

Machine  faults  set  the  appropriate  FT  bit  to  cause  a  machine 
error  interrupt  (provided  it  is  not  masked) .  Certain  machine 
faults  cause  the  current  instruction  to  be  aborted  (see  3.7). 


2.7  SYSTEM  TIMING 


The  MKS1750  uses  a  four-phase  clock.  01  is  used  to  latch 
the  primary  microinstruction  word  into  the  processor  and  gate 
arrays.  02  is  used  to  latch  and  output  the  contents  of  the 
MKS16  scratchpad  during  a  read  cycle.  03  (WAIT)  is  used  to 
synchronize  processor-bus  transactions.  The  processor  waits 
during  this  phase  for  a  bus  access  and  for  the  accessed  slave 
device  to  indicate  transfer  completion.  04  (CLK)  is  used  to 
latch  the  secondary  microinstruction,  the  registers,  the  next 
address  and  the  condition  codes.  A  system  timing  example  is 
shown  in  Fig.  8. 

3.  PRINCIPLES  OF  EMULATION 

3.1  THE  CONTROL  WORD 

The  MKS1750  uses  a  48-bit  microinstruction  word,  shown  in 
Fig.  5.  Bits  Cl  -  C14  and  C18  -  C30  are  used  to  control  the 
MRS 16  processor. 

Several  microinstruction  fields  are  used  to  determine  the 
next  microaddress.  The  high-order  three  bits  (the  BLOCK 
ADDRESS)  are  given  by  C17,  C31,  C32.  C15,  C24  -  30  are  used  to 

form  the  L-address.  C35  -  36  are  used  to  control  the  next 
address  multiplexer  and  return  address  stack. 

The  interpretation  of  bits  C33  -  48  depends  on  the  value  of 
C16.  If  C16  *  1  then  C33  -  48  is  a  16-bit  constant  which  is 
read  by  the  MKS16  from  the  I-bus.  This  provides  arbitrary  con¬ 
stants  without  the  use  of  a  separate  constant  ROM.  If  C16  =  0 
then  C33  -  48  are  external  logic  control  signals.  C33  -  34  con¬ 
trol  XIR  reformatting.  C37  -  38,  C48  control  the  MULTIBUS™ 
interface.  C39  -  40  control  latches  for  the  XIR,  the  memory 
address  register  (MAR)  and  the  register  file.  Register  file 
addressing  and  the  XIR  counters  are  controlled  by  C41  -  45.  C41, 

C46  -  47  control  the  external  condition  multiplexer  for  testing 
the  values  of  the  XIR  counters. 

3.2  CONTROL  STORE  ORGANIZATION 

Control  ROM  is  organized  as  2Kx48.  The  physical  micro¬ 
address  format  is  shown  in  Fig.  6.  The  distinction  between  page 
and  word  address  is  valid  only  for  N-addressing.  The  return 
address  for  a  subroutine  call  is  obtained  by  incrementing  the 
block  address  of  the  calling  microinstruction.  The  microprogram 
is  functionally  partitioned  so  that  floating-point  and  diagnostic 
microcode  resides  in  blocks  4-7,  while  the  rest  of  the  micro¬ 
code  occupies  blocks  0-3,  and  for  this  reason  the  return 
address  generator  increments  the  block  address  modulo  4  rather 
than  modulo  8. 


h  1 7 


Fig.  3-MKS16  Microinstruction  word 
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Fig.  6  -  Physical  Micro  ad  dr  ess  Format 
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3.3  MICROPROGRAM  STRUCTURE 


The  MKS1750  microprogram  makes  extensive  use  of  micro- 
subroutining;  three  levels  are  supported.  The  functions  per¬ 
formed  by  the  subroutines  are  determined  by  analyzing  the  175QA 
instruction  set  in  the  following  areas: 

o  instruction  format 
o  address  mode 
o  length  of  operand  (s) 
o  precision  of  operand  (s) 
o  effect  on  condition  codes 

The  execution  of  a  1750A  instruction  is  divided  into 
several  phases,  each  of  which  requires  only  a  subset  of  the 
above  information.  For  example,  effective  address  calculation 
only  requires  knowledge  of  the  instruction's  address  mode.  All 
effective  address  calculation  routines  return  with  the  address 
loaded  to  the  MAR  and  all  execution  routines  leave  their 
results  in  prespecified  internal  MKS16  registers.  As  a  result, 
there  are  three  "operand  store"  routines,  for  16,  32  and  48-bit 
operands.  Each  arithmetic  operation  has  one  routine  for  each 
applicable  data  type;  there  are  four  ADD  routines,  for  single/ 
double  precision  fixed,  floating  and  extended  floating-point 
numbers.  Effective  address  calculation  is  combined  with  the 
operand  fetch  phase,  so  that  each  1750A  address  mode  has  one 
routine  for  each  applicable  operand  length.  Each  of  these 
routines  is  responsible  for  both  calculating  the  effective 
address  and  fetching  the  correct  number  of  operands. 

3.4  REGISTER  ALLOCATION 

The  MKS16  internal  16x16  register  file  (scratchpad)  is 
used  for  working  registers  and  to  maintain  the  status  of  the 
1750A  machine.  It  is  possible  to  perform  a  read-modify-write 
operation  on  an  internal  register  during  one  microcycle.  In 
addition,  the  MKS16  instruction  register  (IR)  is  used  to  contain 
the  1750A  instruction  word  and  the  MKS16  status  register  (SR) 
is  used  to  maintain  the  1750A  condition  codes.  (See  Fig.  7) 

Registers  0-9  are  available  as  temporary  registers  for 
any  instruction.  Registers  B  -  F  are  used  to  contain  the  1750A 
status.  Register  F  is  dedicated  to  the  instruction  counter; 
register  C  contains  a  copy  of  the  instruction  word.  Register  B 
is  used  by  the  BEX  instruction.  Registers  D  and  E  are  used  in 
conjunction  with  the  MKS16  SR  to  maintain  the  1750A  status  word. 

3.5  INSTRUCTION  EXECUTION 

Instruction  execution  starts  with  the  fetch/decode  phase. 
During  this  phase  the  IC  is  incremented,  the  next  instruction 
is  fetched,  and  the  MKS16  tests  for  a  valid  pending  interrupt. 

If  there  is  a  valid  interrupt  the  fetch  sequence  is  aborted. 


The  next  microaddress  is  determined  by  the  high  byte  of  the 
instruction  fetched,  providing  a  256-way  branch.  The  effective 
address  is  then  calculated  and  the  operand (s)  are  fetched  and 
loaded  to  internal  working  register(s).  For  1750A  immediate 
short  address  modes,  one  operand  is  extracted  from  the  instruc¬ 
tion  word  itself;  for  IC-relative  mode  (branch  instructions) 
the  jump  address  is  calculated  and  loaded  to  a  working  register. 

Final  instruction  decoding  is  performed  at  this  point  for 
base-relative  indexed  and  immediate  long  modes,  and  the  opera¬ 
tion  specified  by  the  instruction  is  performed.  The  result 
is  left  in  internal  register (s) .  Conditional  branch  instructions 
update  the  IC  if  necessary,  and  arithmetic  and  logical  instruc¬ 
tions  update  the  condition  codes  as  required.  The  operand  store 
phase  transfers  the  results  to  the  appropriate  destination, 
usually  the  register  file.  The  number  of  words  transferred  is 
determined  by  the  precision  of  the  instruction. 

3.6  I/O 

The  MKS1750  implements  I/O  instructions  as  follows; 

o  the  command  word  is  loaded  to  the  MAR,  and  the 
processor  issues  an  I/O  bus  request. 

o  the  data  transfer  takes  place  during  the  next  cycle. 

However,  certain  XIO  commands  require  the  microprogram  to 
manipulate  the  status  word  or  interrupt  enable  flag  explicitly. 
The  MKS1750  implements  all  mandatory  1750A  XIO  commands. 

3 . 7  ABORT  FAULTS 

The  1750A  Standard  defines  an  "Instruction  Set  Architecture" 
to  be  the  programmer's  view  of  the  machine.  The  standard  speci¬ 
fies  the  state  of  the  machine  "between  instructions"  and  does 
not  address  what  happens  during  the  execution  of  an  instruction. 
As  a  result,  there  are  certain  "gray  areas"  in  the  standard 
which  must  be  resolved  in  an  implementation-dependent  manner. 

In  particular,  certain  machine  faults  may  occur  as  the 
result  of  a  memory  access  during  the  execution  of  an  instruction. 
If  the  execution  of  the  instruction  is  allowed  to  proceed,  the 
results  are  unpredictable  (e.g.  executing  an  instruction  when 
the  fetch  caused  a  parity  error).  In  the  MKS1750,  this  situa¬ 
tion  is  resolved  by  terminating  the  instruction,  if  any  of  the 
following  "abort  faults"  occur;  CPU  memory  protect  fault, 
memory  parity  fault,  or  illegal  address  fault.  When  such  a 
fault  occurs,  the  microprogram  jumps  immediately  to  an  abort 
fault  handler.  This  microroutine  uses  an  instruction- length  flag 
to  ensure  that  the  IC  saved  during  the  subsequent  machine  error 
interrupt  has  a  consistent  value. 


3.8  FLOATING-POINT  ARITHMETIC 

1750A  floating-point  instructions  are  implemented  in  firm¬ 
ware.  The  MKS16  contains  shift  control  logic  which  permits 
detection  and  automatic  correction  of  partial  product  overflow 
during  multiplication,  and  of  mantissa  overflow  during  floating¬ 
point  addition.  The  microprograms  also  use  some  MKS1750  features 
in  non-standard  ways.  For  example,  the  MKS1750  may  perform 
multiple  operations  and  test  multiple  conditions  simultaneously. 
This  is  used  in  floating-point  normalization,  shown  below.  AR 
and  XR  contain  the  un-normalized  mantissa,  and  XIR  contains  the 
exponent  plus  one,  internally  represented  in  excess  128  form: 


708: 

SLLX  DECSD  TESTSD  TOV 

:  7, Cl,  8 

709: 

RRCX  TOV 

: (exit) 

70A: 

XIR  =  IRCOPY; 

: (underflow) 

70B: 

RRCX  TOV 

: (exit) 

The  instruction  at  708  is  the  single-instruction  normalize  loop. 
It  shifts  the  entire  mantissa  left,  decrements  the  exponent, 
and  tests  two  conditions:  overflow  of  the  mantissa  and  zero 
of  the  exponent.  If  both  are  false,  instruction  708  repeats. 

If  the  exponent  reaches  zero  before  the  mantissa  overflows,  the 
next  instruction  logic  selects  70A,  which  is  the  first  instruc¬ 
tion  of  the  exponent  underflow  handler.  Mantissa  overflow 
indicates  that  normalization  is  complete,  and  the  next  instruc¬ 
tion  logic  selects  either  709  or  70B,  depending  upon  whether 
the  exponent  has  reached  zero.  Either  case  is  acceptable,  and 
so  both  instructions  perform  a  right  shift  to  correct  for  the 
mantissa  having  been  shifted  one  bit  too  far. 

3.9  ARCHITECTURAL  INSTRUCTIONS 

Several  1750A  instructions  require  special  attention.  For 
example: 

o  TSB  -  the  microprogram  inhibits  external  memory 
accesses  during  a  TSB  instruction  by  issuing  a 
bus  request  every  cycle,  which  causes  the  arbitra¬ 
tion  logic  to  lock  the  bus. 

o  MOV  -  the  microprogram  checks  for  the  presence 

of  a  valid  interrupt  between  each  single-word  trans¬ 
fer.  In  addition,  for  the  MOV  instruction  the  micro¬ 
program  does  not  increment  the  value  of  the  instruc¬ 
tion  counter  until  all  transfers  are  completed. 

Thus,  if  an  interrupt  occurs  and  is  serviced,  on 
return  the  execution  of  the  MOV  instruction  will 
start  over  again.  This  scheme  produces  the  desired 
result  since  the  registers  used  by  the  MOV  instruc¬ 
tions  always  contain  the  correct  values. 


Fig.  7  MKS16  Register  Allocation 


MKS1750  IMPLEMENTATION 


4 . 1  FUNCTIONAL  PARTITIONING 

The  partitioning  is  hased  on  a  1400-gate  102-pin  SOS/CMOS 
universal  array  manufactured  by  RCA.  The  MKS1750  logic  is 
partitioned  into  three  arrays.  The  boundaries  of  each  array 
are  shown  as  broken  lines  in  Fig.  1.  The  emulating  controller 
unit  (ECU)  contains  the  logic  required  for  microsequencing,  XIR 
manipulation,  and  external  register  control.  The  bus  controller 
unit  (BCU)  handles  bus  transfers,  system  timing,  logical 
addressing,  and  bus  arbitration.  The  interrupt  controller  unit 
( ICU)  processes  interrupt  requests  and  executes  mandatory  XIO 
instructions  for  Pi,  MK  and  FT.  The  external  16x16  register 
file  is  implemented  using  a  second  MKS16  chip.  Six  2Kx8  ROMs 
are  used  for  control  store. 

4.2  EMULATING  CONTROLLER  UNIT  (ECU) 

The  ECU  contains  the  logic  required  for  instruction  decode, 
register  control,  and  microsequencing.  The  XIR  provides  in¬ 
struction  fields  for  register  addressing.  A  3x11  microaddress 
stack  allows  microsubroutining. 

The  XIR  may  be  read  into  the  MKS16  from  the  I-bus.  The 
value  may  be  modified  to  facilitate  instruction  decoding,  as 
follows : 

C16  C33  C34  OPERATION 

000  NOP:  no  operation 

001  SWAB:  swap  bytes 

010  SWSD:  swap  S  and  D  fields 

Oil  SEXT:  extend  sign  of  low  order  byte 
1  X  X  read  16-bit  constant 

The  register  file  may  be  addressed  by  the  XIR  S  or  D  fields,  or 
by  a  four-bit  literal  address.  The  counters  are  controlled  as 
follows: 


OPERATION 

NOP 

DEC ( SD) : 
NOP 

INC (SD) : 
DEC ( S ) : 
INC (S)  : 
DEC ( D ) : 
INC (D)  : 


8-bit  decrement 

8-bit  increment 

4-bit 

4-bit 

4-bit 

4-bit 


Bits  C16,  C35  -  36,  C46  -  47  are  used  to  control  the  micro¬ 
sequencer. 


4.3  INTERRUPT  CONTROLLER  UNIT  (ICU) 


The  ICU  contains  the  logic  required  for  the  MIL-STD-1750A 
PI,  MK  and  FT.  In  addition,  a  valid  interrupt  request  to  the 
processor  is  generated  according  to  the  following  equation: 

valid  interrupt  =  PI„  +  PI-  +  CPI  • MK  )  • ENB  +  PI,  •  MK, 

0  5  n  n  11 

where  n  =  2,  3,  4,  6-15  and  ENB  is  the  interrupt  enable 

flag. 

The  Pending  Interrupt  Register  is  a  set  of  sixteen  flip- 
flops  which  are  set  and  reset  using  the  RPI,  SPI  and  RPIR  XIO 
commands.  The  Interrupt  Mask  Register  is  a  set  of  sixteen 
flip-flops  which  are  set  and  reset  using  the  SMK  and  RMK  XIO 
commands.  MK  is  also  saved  and  restored  as  part  of  the  pro¬ 
cessor  context  by  the  interrupt  microprogram. 

When  an  XIO  instruction  is  executed,  the  16-bit  command 
field  is  loaded  to  the  MAR,  and  an  I/O  request  is  issued.  For 
mandatory  XIO  commands,  no  system  bus  access  is  required.  If 
the  XIO  command  is  not  local  (such  as  a  programmed  I/O  channel) , 
then  bus  arbitration  is  required.  A  timeout  will  occur  if  the 
I/O  device  is  not  present,  and  the  appropriate  FT  bit  is  set. 

The  Fault  Register  is  a  set  of  sixteen  RS  flip-flops  used 
for  indicating  machine  faults.  Setting  any  FT  bit  causes  bit 
1  of  PI  to  be  set.  The  FT  is  controlled  by  the  RCFR  XIO  command. 

4.4  BUS  CONTROLLER  UNIT  (BCU) 

The  BCU  provides  logic  to  address  memory  and  I/O  devices, 
synchronize  bus  transfer  cycles,  supply  processor  clocks,  and 
interface  to  the  MULTIBUS™.  A  16-bit  logical  address  is  pro¬ 
vided  by  loading  the  MAR  prior  to  a  bus  transfer.  For  memory 
management,  the  AS  and  PS  fields  of  the  SW  are  loaded  to  the 
8-bit  External  Status  Register  (XSR) . 

During  the  request  cycle,  the  address  of  the  slave  device 
(I/O  or  memory)  is  latched  into  the  MAR  if  the  device  is  not 
local,  a  bus  request  is  issued,  and  the  transfer  type  is  latched. 
During  the  transfer  cycle,  the  processor  can  access  the  bus  if 
no  higher-priority  device  is  requesting  it.  The  processor  delays 
the  CLK  phase  until  XACK  is  received.  CLK  is  then  used  to  latch 
the  slave  data  into  a  register,  XIR,  or  MAR. 

4.5  PACKAGING  CONSIDERATIONS 

The  MKS1750  microprocessor  is  packaged  as  a  set  of  eleven 
hermetically-sealed  leadless  chip  carriers,  which  are  standard 
JEDEC  types.  This  includes: 

o  three  132-pin  type  A  carriers,  for  SOS  gate  arrays 

o  two  48-pin  type  C  carriers,  for  the  MKS16  and  register 
file 


o  six  32-pin  type  C  carriers,  for  2Kx8  control  ROMs 

Leadless  carriers  provide  greater  packaging  density  as  they 
are  smaller  than  conventional  DIPs  and  the  shorter  lead  lengths 
improve  the  switching  characteristics  of  the  processor.  The 
chip  set  may  be  mounted  on  a  small  ceramic  card  to  accomodate 
the  particular  application  form  factor  required  (6). 

4 . 6  SOFTWARE  SUPPORT 

Software  support  for  MKS1750  development  is  based  on  the 
MIL-STD-1750A  Support  Software  Package  which  was  developed  by 
McDonnell-Douglas  under  USAF  contract.  This  package  includes 
a  macropreprocessor,  assembler,  linker,  1750A  simulator  and 
utilities  for  formatting  and  library  maintenance. 

This  package,  installed  on  a  local  IBM  3033  VM/CMS  time¬ 
sharing  system,  was  used  to  develop  a  resident  monitor/debugger 
for  the  MKS1750.  This  monitor  is  compatible  with  the  support 
software  package,  and  allows  users  to  develop  and  debug  1750A 
software  during  system  prototyping.  The  monitor  supports  "quick 
look  and  change"  commands  for  memory  and  1750A  registers,  down¬ 
line  loading  of  1750A  programs  developed  using  the  support 
package  and  program  execution  under  breakpoint  control.  The 
monitor  also  includes  I/O  utilities  to  support  two  serial  RS232C 
lines  (for  a  terminal  and  downline  loading)  and  optional  dual 
floppy  disk  drives. 

4.7  MKS1750  SUMMARY  SPECIFICATIONS 

ARCHITECTURE  full  implementation  of  MIL-STD-1750A 

(Notice  1) ,  based  on  16-bit  micropro- 
grammable  processor 

TECHNOLOGY  SOS/CMOS  -  eleven  chips 

POWER 

DISSIPATION  less  than  1W  at  5.5  MHz,  10V 

TEMPERATURE  -55°C  to  +125°C 

SIZE  4  x  4  x  0.5  in.  (typical) 

RADIATION  . n  . 

RESISTANCE  10x  rad  (Si)  transient,  10  rad  total 

dose 

MICROCYCLE  180  nsec 

TIME 

265  KIPS  (100  nsec  memory) 

240  KIPS  (250  nsec  memory) 

using  DAIS  mix  (16%  floating-point) 

450  -  540  KIPS  (fixed  point  only) 


PERFORMANCE 


ADDRESS  SPACE  64K  Coptional  memory  management) 

EXTERNAL 

INTERFACE  MULTIBUSw-compatible 

5.  SUMMARY 

The  MKS1750  is  a  new  hardware/ firmware  realization  of  the 
standard  1750A  architecture.  The  eleven-chip  set  is  an  all 
SOS/CMOS  microprocessor  which  is  high  performance,  low  power, 
small  in  size  and  radiation  resistant.  These  features  make  the 
MKS1750  attractive  for  a  variety  of  Air  Force  and  other  embedded 
computer  applications. 
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ABSTRACT 

Texas  Instruments,  as  part  of  its  very-high-speed  integrated  circuit  (VHSIC)  contract 
with  the  Army,  is  developing  a  4-million  instruction-per-second  (MIPS) 

MIL-STD-1 750A  data  processor.  This  paper  describes  the  design  goals,  implementation 
approach,  and  key  features  of  the  design. 

The  1750A  processor  is  composed  of  four  device  types.  A  25-MHz  data  processor 
unit  (DPU)  and  device  interface  unit  (DIU)  implement  all  1 750A  instructions,  including 
floating  point  and  approved  extensions  to  aid  operating  system  functions,  and  the 
interfaces  to  support  the  interrupt  structure,  memory  extension  and  I/O  command  struc¬ 
ture  defined  by  MIL-STD-1 7  50 A.  One  or  more  general  buffer  units  (GBUs)  provide 
interfaces  to  other  processors  and/or  I/O  devices  via  a  network  of  multimaster  buses. 
These  logic  devices  are  supported  by  a  25-nanosecond  64K-bit  (8K  X  9)  static  RAM  to 
achieve  an  expected  4-MIPS  performance  on  the  DAIS  mix. 

The  paper  concentrates  on  the  architectural  approach  to  the  implementation  and  the 
hardware  and  instruction  extension  features  that  support  operating  system  functions, 
higher  order  languages,  and  maintenance  and  test  functions  and  interfaces  to  peripheral 
devices. 

INTRODUCTION 

Advanced  USAF  aircraft  weapon  systems  will  have  many  requirements  for 
high-speed,  high-density  1750A  processors.  These  processors  must  provide  the  required 
high  throughput,  low-cost  maintenance  operations,  very-high  reliability  and,  in  critical 
applications,  fault-tolerant  computing  capabilities  of  future  avionics  systems. 

An  IC  chip  set  is  being  developed  under  the  Texas  Instruments  VHSIC  Phase  1 
contract  to  meet  these  advanced  1 7  50 A  needs.  At  the  center  of  this  chip  set  is  a 


monolithic  microprocessor,  the  DPU,  which  executes  the  full  MIL-STD-1750A  instruc¬ 
tion  set  plus  several  legally  implemented  extensions.  The  performance  of  this  micro¬ 
processor  will  be  in  the  4-  to  6-MIPS  range  against  an  integer  mix,  and  between  2  and  4 
MIPS  against  a  DAIS  mix.  A  second  coprocessor,  the  DIU,  supports  the  1750A  micro¬ 
processor  by  handling  all  interfacing  to  the  outside  world.  The  referenced  instruction  set 
extensions,  in  part,  provide  direct  microcode  support  for  prioritized  task  scheduling  and 
other  operating  system  and  multiprocessor  communications  functions. 

Performance  is  not  the  only  driving  factor  guiding  the  development  of  the  Texas 
Instruments  VHSIC  chips.  Maintainability,  testability,  and  fault-tolerant  capabilities  are 
also  important.  Built-in  test  features  are  being  provided  on  all  ICs  to  allow  self-testing  at 
the  processor  level.  These  features  include  a  4-bit  maintenance  port  for  interfacing  to  a 
serial  bus  that  can  be  tied  to  an  external  maintenance  controller.  Fault-tolerant 
computing  is  provided  for  via  on-chip  memory  error  correction  and  a  2-bit  voting  port 
for  triply  redundant  processor  operations. 

PROCESSOR  DESIGN  PHILOSOPHY 

The  processor  design  is  primarily  targeted  toward  small  embedded  signal  processing 
applications  where  size,  power,  and  throughput  are  the  most  important  considerations. 
However,  the  design  provides  all  of  the  necessary  “hooks”  to  fully  support  a 
large-machine,  laboratory-development  type  environment  in  such  a  way  that  the  small 
embedded  applications  are  not  impacted.  Careful  studies  of  current  embedded  computer 
requirements  produced  the  following  design  guidelines: 

•  16-  and  32-bit  integer  operations  were  most  prevalent.  However,  DoD 
requirements  for  HOL  programming  added  emphasis  to  the  need  for  fast, 
single-precision,  floating-point  arithmetic. 

•  Special  hardware  support  of  HOL  and  OS  functions  wculd  be  required  to 
encourage  systems  designers  to  migrate  to  an  HOL  environment. 

•  The  majority  of  the  size  and  power  in  microprocessor-based  systems  was  a 
result  of  random  TTL  support  logic,  not  the  microprocessor  device.  Therefore, 
the  microprocessor  should  absorb  as  many  support  functions  as  possible. 

•  The  constraining  performance  factor  would  be  memory  access  time.  Therefore, 
the  memory  path  must  be  short,  well  controlled,  and  free  of  all  unnecessary 
capacitive  loading. 

•  A  memory  size  of  64  K  words  would  be  adequate  for  most  embedded  systems. 
Larger  memories,  however,  must  also  be  supported  with  some  reasonable 
penalty  in  performance.  Memory  caching  for  large  system  memories  was  a 
logical  assumption. 

•  Direct  hardware  support  for  tightly  coupled  multiprocessor  systems  was  a 
requirement. 
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•  Fail-soft  capability  was  required  in  some  systems.  The  capability  should  be 
provided  with  minimum  impact  on  the  simple  processor  case,  however. 

•  I/O  operations  (channel-type  DMA  and  messages)  should  be  supported  in 
parallel  with  normal  processing  for  increased  system  throughput. 

•  Device  pinout  should  be  restricted  to  a  maximum  of  84  pins  to  facilitate  device 
fabrication,  improve  reliability,  and  decrease  PWB  footprint  area. 

The  above  guidelines  dictated  the  processor  partitioning  and  I/O  techniques  to  be 
used,  while  MIL-STD-1750A,  Notice  1,  dictated  the  instruction  set  architecture  and 
allowable  extensions. 

1 750 A  PROCESSOR  DESCRIPTION 

The  1750A  processor,  illustrated  in  Figure  1,  is  composed  of  two  primary  device 
types:  the  data  processing  unit  (DPU)  and  the  device  interface  unit  (DIU),  supported  by 
static  random-access  memories  (SRAMs)  and  general  buffer  units  (GBUs).  The  DPU  and 
DIU  perform  all  processing  and  I/O  related  functions.  The  SRAMs  provide  all  storage 
for  instructions  and  data,  with  the  exception  of  the  kernel  operating  system  located  in 
ROM  on  the  DIU.  The  GBUs  provide  all  interfaces  to  other  processors  and  I/O  devices 
via  a  network  of  multimaster  buses  called  system  buses  (SBUSs). 

Each  1750A  processor  is  completely  self-contained.  Construction  of  a  multi¬ 
processor  system  consists  of  simply  strapping  the  appropriate  SBUS  connections  to 
establish  the  system  bus  configuration.  Programming  of  a  multiprocessor  system  is 
independent  of  the  bus  configuration  or  the  number  of  processors  in  the  system.  This 
configuration  information  is  supplied  in  table  form  to  the  “binder.”  the  last  step  in 
system  software  configuration.  The  system  bus  configuration  can  also  be  altered  dynami¬ 
cally  to  compensate  for  failed  buses  or  nodes  by  changing  a  single  software  pointer,  no 
restructuring  of  programs  is  required. 

Special  instruction  extensions  have  been  added  to  the  processor  in  accordance  with 
MIL-STD-1750A,  Notice  1,  to  allow  software  to  view  a  multiprocessor  system  as  a 
single  processor  with  a  single  address  space. 

The  Data  Processing  Unit 

The  DPU  is  a  high-performance  microprocessor  that  conforms  to  the  instruction  set 
architecture  established  by  MIL-STD-1750A,  Notice  1,  plus  approved  extensions.  The 
processor  implements  all  1 7 50 A  instructions,  including  floating-point  arithmetic,  and  all 
required  interfaces  to  support  the  interrupt  structure,  memory  extension,  and  I/O 
command  structure  defined  by  MIL-STD-1750A. 

The  processor  architecture  provides  autonomous,  multilevel  instruction  lookahead 
as  well  as  autonomous  lookahead  address  development.  The  major  arithmetic  path, 
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composed  of  the  1 6-word  general  register  file,  1 0-word  accumulator  register  file,  operand 
select  logic,  32-bit  arithmetic  logic  unit  (ALU),  and  32-bit  barrel  shift/align/normalize 
logic,  provides  3  2-bit- wide  arithmetic  paths  for  increased  throughput  on 
double-precision  and  floating-point  operations. 

Memory  interfacing  is  simplified  by  built-in  chip  enable  decoding,  memory 
device-compatible  interface  signals,  built-in  memory  error  correction,  and  onboard  sup¬ 
port  for  memory  extension  to  1  million  words. 

Approved  extensions,  in  the  form  of  a  universal  user/executive/hardware  procedure 
call,  automatic  hardware  task-scheduling,  semaphore  operations,  message  operations, 
interprocessor  communications,  and  other  operating  system  type  functions,  have  been 
added  via  the  BIF  opcode,  provided  by  MIL-STD-1 750A,  Notice  1,  to  fully  support 
Pascal,  JOVIAL,  Ada  and  other  high-order  languages.  Several  registers,  including  the 
pending  task  (PT)  register,  and  the  extended  fault  (EFT)  register,  have  been  added  to 
support  these  insruction  extensions.  A  special  configuration  register  (CFR)  has  also  been 
added  to  guarantee  object  code  compatibility  with  user  code  generated  per  the  basic 
MIL-STD-1 750A  specification,  without  the  new  extensions.  These  registers,  and  an 
extended  definition  of  the  status  register,  are  defined  in  Table  1 . 

Interfaces  are  provided  for  maintenance  and  test,  and  for  a  unique,  triply  redundant, 
voting  technique  to  fully  support  high-reliability  systems  requirements.  A  four-line  inter¬ 
face,  called  the  system  maintenance  bus(SMBUS),  provides  self-test  initiation/reporting, 
conventional  “front  panel”  functions  such  as  examine/modify  registers,  halt/step/break¬ 
point,  etc.,  and  error  reporting  for  the  voting  logic.  The  two-line  voting  bus  allows  two 
processing  units  (two  DUPs  and  two  DIUs)  to  be  strapped  pin-for-pin  as  “worker”  and 
“watcher”  to  provide  clock-by-clock  voting  and  automatic  shutdown  on  any  discrep¬ 
ancy.  Three  processing  units  (three  DPUs  and  three  DIUs)  designated  as  “worker,” 
“watcher,”  and  “surrogate”  may  also  be  strapped  pin-for-pin  for  “fail-soft”  operation 
wherein  the  watcher  and  surrogate  monitor  and  vote  on  the  operation  of  the  worker  on  a 
clock-by-clock  basis.  In  this  mode,  the  surrogate  will  override  and  replace  the  worker  on 
any  discrepancy  while  the  watcher  continues  to  monitor  the  surrogate. 

The  Device  Interface  Unit 

The  DIU  is  a  special-purpose  co-processor  designed  as  a  companion  for  the  data 
processing  unit  to  provide  all  outside  interfaces  other  than  memory.  The  DIU  performs 
programmable  I/O,  channel  I/O,  message  transactions,  interprocessor  interlock  (sema¬ 
phore)  operations,  and  other  functions  in  parallel  with  the  data  processing  unit. 

Interfaces  to  peripherals  and  other  processors  are  provided  by  the  DIU’s  system  bus 
(SBUS),  a  high-speed,  multiuser,  synchronous  bus  that  supports  I/O  commands, 
messages,  and  bulk  data  transfers  at  a  sustained  rate  of  one  word  per  clock.  The  majority 
of  the  DIU  is  dedicated  to  the  support  of  SBUS  communication. 


Table  1.  Register  Extensions/ Additions 


EXTENDED  STATUS  WORD 

0  3  4  7  8  1112  15 


CS  ASD,  PS 


'SPARE  IN  NATIVE  1750A  MODE,  SEPARATE  ADDRESS  AND  DATA  STATES 
IN  TASK  CONTROL  BLOCK  AND  CALLS  DATA  STRUCTURES  ONLY  FOR  USE 
WITH  INSTRUCTION  EXTENSIONS. 


EXTENDED  FAULT  REGISTER 
0  3  4 


MEMORY 

ERRORS 


MULTIPROCESSOR 

SUPPORT 


DEVICE  ERRORS,  SEMAPHORES/ STACK 
OVERFLOWS  AND  SOFTWARE  TIME-OUT 


ERROR-CORRECTED  MEMORY  FAULTS 


PENDING  TASK  REGISTER/CURRENT  PRIORITY  REGISTER 


Functionally,  the  DIU  operates  as  a  microcoded  interpreter  that  is  driven  by 
descriptors  from  a  series  of  linked-list  queue  structures  in  memory.  These  descriptors  are 
“cached”  in  the  channel  control  and  address  register  files  during  interpretation.  The 
actual  interpreter  is  composed  of  the  main  ROM  controller,  the  channel  status  register 
(CST)  that  maintains  queue  activity,  and  a  limited  function  16-bit  ALU. 

The  memory  data  and  address  paths  and  associated  registers  are  identical  to  those  in 
the  DPU,  providing  a  simple  memory  interface  with  memory  error  correction.  A  second 
data  path  is  provided  for  FIFO  buffering  of  SBUS  communications  by  a  separate  autono¬ 
mous  controller. 

The  DIU  also  provides  three  programmable  timers,  per  the  MIL-STD-1 750A  speci¬ 
fication,  and  a  2K  by  16  ROM  that  contains  a  complete  kernel  operating  system,  suffi¬ 
cient  for  small  embedded  computer  systems,  plus  bootstrap  loaders  and  self-test  routines. 
The  primitives  provided  by  this  operating  system  are  universally  applicable  across  all 
languages.  Furthermore,  the  various  routines  are  accessed  indirectly  through  a  tables 
structure  in  SRAM,  allowing  any  or  all  of  the  routines  to  be  replaced  by  user-written 
routines.  Additional  entries  have  been  provided  in  the  table  structures  to  allow  extension 
of  the  operating  system  for  more  general-purpose  central  avionics-type  applications  and 
for  laboratory-type  multiuser,  virtual-memory  type  environments. 

The  DIU  also  supports  the  system  maintenance  bus  as  a  slave  to  the  data  processing 
unit  to  facilitate  node  level  maintenance  as  well  as  the  triply  redundant  voting  bus  for 
high  reliability  system  applications. 

The  General  Buffer  Unit 

The  GBU  provides  communication  between  array  processors,  data  processors,  and 
peripheral  devices  within  a  network  of  processor  nodes.  The  network  can  be  configured 
with  several  bus  levels,  each  of  which  is  a  multimaster  bus  with  a  separate,  possibly 
asynchronous,  clock.  Each  level  in  the  network  can  support  up  to  1 6  master  devices;  also, 
additional  slave  devices  and  multiple  redundant  paths  may  be  provided  between  devices 
for  increased  bandwidth  and/or  fault  tolerance.  The  GBU  operates  in  one  of  two  major 
modes  (coupler  or  PIO)  with  many  minor  modes,  all  of  which  are  software 
programmable. 

In  the  coupler  mode,  the  GBU  waits  for  commands  or  messages  on  one  bus,  and  if  a 
bus  relay  is  required,  vies  and  becomes  master  on  the  other  bus  to  relay  the  command  or 
message  to  the  next  level  device.  Once  a  path  has  been  established  between  an  originating 
device  and  its  target  device,  information  is  transferred  as  a  stream  of  16-bit  words.  The 
transfer  of  information  is  buffered  by  a  two-level  FIFO  at  each  bus  level,  creating  the 
equivalent  of  a  single  FIFO  buffer  of  arbitrary  length  between  the  originating  device  and 
the  target  device.  This  technique  allows  information  to  be  transferred  at  a  rate  of  one 
1 6-bit  word  per  bus  clock  at  the  clock  rate  of  the  slowest  bus  clock  encountered  in  the  se¬ 
lected  path. 


Each  bus  transaction  is  either  a  command  or  a  message.  All  transactions  begin  with  a 
16-bit  header  word  that  specifies  the  type  of  transfer  (input  or  output,  command  or 
message,  etc.)  and  an  8-bit  path  name  that  uniquely  specifies  the  network  path  from  the 
originator  to  the  target  device.  This  header  word  is  followed  by  a  variable-length  data 
stream  whose  length  and  content  are  dependent  on  the  header-type  fields. 

In  PIO  mode,  the  GBU  interfaces  the  SBUS  to  a  simple  16-bit  parallel  I/O  device. 
Each  bit  may  be  independently  programmed  as  input  or  output  to  support  16-bit 
single-word  transfers  or  discrete  control  bit  requirements.  An  “interrupt”  capability  is 
also  provided  so  that  the  GBU  can  issue  a  device  service  request  message  to  any  system 
processor  in  response  to  a  change  in  one  of  the  input  discretes. 

The  GBU  also  supports  the  SMBUS  for  self-test  and  maintenance  operations,  in 
addition  to  the  normal  operational  interfaces. 

Static  RAM 

The  SRAM  is  an  8  K  by  9  static  NMOS  memory  with  special  peripheral  logic  to 
support  the  processor  devices.  The  SRAM  provides  the  write-protect  bit  storage  and 
protection  logic  necessary  to  implement  the  block  write-protect  option  specified  by 
MIL-STD-1750A.  Each  IK  block  of  memory  can  be  individually  protected  by  software 
I/O  commands  so  that  stored  data  cannot  be  modified.  Any  attempt  to  modify  protected 
data  will  result  in  a  processor  interrupt. 

The  SRAM  also  provides  simple  byte  parity  generation  and  checking.  Or,  the  data 
processor  may  utilize  all  1 8 -bits  (two  SRAMs  wide)  with  parity  generation  and  checking 
performed  by  the  DPU  and  DIU  devices  to  achieve  maximum  throughput  and  to 
provide  additional  software  fault-isolation  capabilities.  Alternatively,  three  SRAMs  may 
be  used  to  provide  a  22-bit  memory  with  full  single-correct/double-detect  error  correc¬ 
tion  provided  by  both  the  DPU  and  DIU. 

All  address  and  control  signals  are  pipelined  by  registers  on  the  SRAM  device  so  that 
only  one  bus  propagation  delay  is  added  to  the  base  memory  access  time  in  determining 
the  maximum  processor  clock  rate.  The  write  pulse  is  internally  generated,  freeing  the 
processor  (or  system  designer)  from  the  burden  of  generating  precise  timing  strobes  and 
allowing  the  SRAM  to  be  accessed  as  one  would  normally  access  a  register  file. 

PROCESSOR  OPERATION 

Task  Scheduling 

The  DPU  maintains  1 6  prioritized,  linked-list  queues  of  tasks  to  be  executed.  Tasks 
are  automatically  scheduled  by  the  DPU  during  the  execution  of  certain  OS  support 
instruction  extensions,  such  as  semaphore  instructions.  This  mechanism  eliminates  the 
majority  of  the  overhead  normally  associated  with  OS  cals  for  task  interlocks  and  task 


scheduling,  allowing  separately  compiled  tasks  to  execute  and  communicate  with  an 
efficiency  similar  to  a  single,  larger  task.  The  DPU  also  supports  special  user-task  and 
executive-task  procedure  call  mechanisms  that  eliminate  the  majority  of  the  overhead 
normally  associated  with  these  functions.  This  allows  compiler-generated  code  to 
execute  with  an  efficiency  similar  to  hand-generated  assembly  language.  These  features 
provide  the  functionality  and  efficiency  necessary  to  encourage  the  system  designer  to 
migrate  to  a  high-level  language  environment. 

The  majority  of  the  communications  between  the  DPU  and  DIU  are  accomplished 
through  manipulation  of  linked-list  queue  structures  in  memory.  This  technique 
provides  FIFO  buffering  of  communications,  releasing  the  DPU  to  continue  processing 
on  the  same  task  or  another  task  while  the  DIU  services  a  channel  I/O  request,  message 
request,  semaphore  operation,  etc.,  to  promote  concurrent  DPU  and  DIU  operation  and 
optimize  the  use  of  available  memory  bandwidth.  Tasks  are  automatically  suspended 
during  such  operations  and  automatically  rescheduled  upon  completion  of  the  operation. 

I/O  Operations 

The  1 750A  supports  five  basic  modes  of  device  interfacing:  ( 1)  an  intelligent  device 
may  be  interfaced  as  an  SBUS  master/slave,  or  (2)  an  SBUS  slave  only,  (3)  a  simple  I/O 
device  may  be  interfaced  to  a  GBU  (operating  in  PIO  mode)  on  the  SBUS,  (4)  a  “special” 
device  may  be  interfaced  directly  to  the  DIU’s  SBUS  using  reserved  17 50 A  I/O 
commands  that  are  not  recognized  by  the  GBUs,  (5)  I/O  devices  may  be  interfaced  as 
( •  “memory-mapped”  functions,  although  this  type  of  interfacing  is  discouraged  because  of 
the  additional  capacitive  loading  on  the  memory  bus. 

All  SBUS  devices,  whether  master/slave,  slave  only,  or  PIO,  interface  to  the  SBUS 
through  one  or  more  levels  of  GBUs  that  provide  for  the  routing  of  commands  or 
messages  and  synchronization  of  different  clock  rates.  Up  to  254  devices  may  be  accessed 
by  a  given  processor  with  any  given  programmation  of  the  GBU  bounds  registers.  This 
restriction  applies  only  to  a  single  processor,  not  to  a  multiprocessor  system.  Likewise,  a 
processor  can  dynamically  reconfigure  the  bound  registers  of  the  GBUs  in  a  system  in 
order  to  reach  other  devices  in  the  system.  This  interfacing  method  is  the  preferred 
method  since  it  provides  the  most  flexibility,  fault  tolerance,  and  bandwidth  (for 
multiword  transfers). 

The  special  I/O  commands  can  only  be  used  to  access  devices  attached  directly  to  the 
DIU’s  SBUS.  These  commands  execute  with  less  overhead  than  the  normal  SBUS 
commands  (PICn,  POCn)  because  no  priority  vies  or  routing  comparisons  are  required. 
The  special  commands  are  supported  by  the  Pascal  compiler  and  other  support  software 
in  the  same  manner  as  the  normal  SBUS  commands  and  are  covered  by  the  same 
protection  mechanism. 

The  system  designer  is  advised  to  provide  external  data  concentration  circuitry,  or 
buffer  memories,  for  sensors  that  input  data  sporadically  in  small  quantities.  These 


buffer  memories  can  then  be  transferred  into  the  1 750A  processor  using  a  high-band- 
width  channel  transfer  to  use  the  available  memory  bandwidth  to  best  advantage. 

Multiprocessor  Support 

The  1 750A  has  been  extended  to  encourage  the  use  of  multiple-processor  systems,  in 
lieu  of  single,  special-purpose  processors,  and  to  promote  standard,  modular  hardware 
and  software  for  future  system  designs.  Processor  modules  can  be  connected  as  a  multi¬ 
processor  system  simply  by  connecting  one  or  more  SBUS  ports  from  each  processor  in 
parallel.  Special  instruction  extensions  have  been  added  to  the  processor  to  ( 1 )  forward 
results  or  operands  from  a  task  in  one  processor  to  a  task  in  a  different  address  state  of  a 
different  processor,  (2)  to  interlock  the  execution  of  tasks  within  a  processor  or  between 
processors,  (3)  to  send  messages  between  the  ROM-based  operating  systems  of  different 
processors,  and  (4)  to  transfer  blocks  of  data  between  the  local  memories  of  different 
processors,  and  other  operations  necessary  to  allow  the  system  software  to  view  a  multi¬ 
processor  system  as  a  single  entity,  thereby  simplifying  the  design  and  programmation  of 
a  multiprocessor  system. 

INSTRUCTION  EXTENSIONS 

The  1 7  50 A  data  processor  incorporates  several  architectural  extensions  to  minimize 
operating  system  overhead,  promote  the  use  of  high-level  languages,  and  facilitate  the 
design  and  programming  of  multiprocessor  systems.  These  extensions  are  embodied  in  a 
set  of  new  instructions  added  via  the  BIF  opcode-approved  MIL-STD-1 750A,  Notice  1 . 

All  extended  operations  instructions  follow  a  single  format  that  is  compiler-gener¬ 
ated  as  an  in-line  procedure/function  call.  The  extended  operation  instructions  consist  of 
three  basic  classes:  noninterrupt  task  procedure  calls,  executive  procedure  calls,  and 
hardware-implemented  function  calls.  This  singular  format  for  all  compiler-generated 
procedure  calls  simplifies  code  compilation  and  significantly  increases  execution  effi¬ 
ciency.  All  parameters  for  hardware  function  calls  or  executive  calls  and  the  first  six 
words  of  parameters  for  user  task  calls  are  passed  through  dedicated  registers  consistent 
with  normal  compiler  usage. 

User  task  procedure  calls,  or  CALLS  instructions  with  operation  codes  4F0Q-4F7F, 
have  a  procedure  number,  ranging  from  0  to  127,  that  is  used  as  an  index  into  the 
Procedure  Entry  Table  (PET)  specified  by  a  pointer  in  the  Task  Control  Block  of  the 
active  task. 

The  CALLS  saves  the  instruction  counter  and  general  registers  of  the  calling  proce¬ 
dure  on  the  process  stack,  allocates  a  new  stack  frame  for  the  calling  procedure,  adjusts 
the  map  registers  if  necessary,  and  begins  execution  of  the  called  procedure.  The  CALLS 
does  not  attempt  to  pass  parameters  (other  than  those  passed  in  the  general  registers), 
allocate  local  variables,  perform  type  checking,  or  any  other  function  that  might  be 
language-dependent. 


The  remaining  extended  operation  codes  (4F80-4FFF)  are  shared  by  the  executive 
call  instruction  and  hardware-implemented  functions.  Hardware-implemented  func¬ 
tions  are  assigned  opcodes  in  descending  order,  beginning  with  opcode  4FFE  with  opcode 
4FFF  reserved  as  an  escape  to  a  two-word  instruction  format  or  to  a  coprocessor- 
implemented  function.  Executive  call  functions,  called  XCALLs,  are  assigned  in 
ascending  order,  beginning  at  opcode  4F80.  This  scheme  allows  maximum  flexibility  in 
transitioning  operating  system  functions  into  hardware  as  device  technology  advances. 

When  the  processor  encounters  an  opcode  in  the  range  4F80-4FFF,  it  first  checks  to 
see  if  the  function  is  implemented  in  hardware.  If  not,  the  seven  LSBs  of  the  opcode  are 
used  as  an  index  into  the  XCALL  Entry  Table  (XET),  which  is  referenced  through  a 
pointer  in  dedicated  memory.  The  executive  task  is  scheduled  on  the  Pending  Task 
Queue  selected  by  the  priority  field  in  the  selected  Task  Control  Block,  just  as  any  other 
task  is  scheduled. 

The  hardware-implemented  functions  currently  defined  are  grouped  into  six  major 
categories:  (1)  function  returns  that  pass  results  back  from  user  functions,  (2)  data 
forwarding  instructions  that  allow  an  operand  to  be  stored  directly  into  the  address  space 
of  another  task  in  any  address  state  of  any  processor  and  the  SYNC  instruction  that 
performs  the  data  flow  update  operation  when  the  processor  is  in  data  flow  mode,  (3) 
semaphore  instructions  that  can  reference  a  semaphore  in  any  address  state  of  any 
processor,  (4)  queue  manipulation  instructions  that  can  operate  on  queue  structures  in 
any  address  state  of  a  processor,  (5)  CORDIC  primitive  instructions  that  allow  efficient 
calculation  of  all  transcendental  functions  with  user  selection  of  number  base  and  user 
optimization  of  accuracy  versus  execution  time,  and  (6)  a  group  of  miscellaneous  func¬ 
tions  for  moving  data  across  address  state  boundaries,  tagging  memory  for  software  error 
detection,  changing  task  priorities,  and  initiating  software  messages.  The  registers  added 
to  support  the  instruction  extensions  are  detailed  in  Table  1  and  the  hardware-imple¬ 
mented  instructions  are  described  in  Table  2. 

This  paper  is  intended  only  to  give  the  reader  a  preview  of  the  characteristics  of 
Texas  Instruments  VHSIC  1750 A  processor,  a  complete,  user-oriented  specification  will 
be  released  upon  completion  of  the  processor  design  validation  effort. 


Table  2.  Special  Procedure  Instructions 
OpCodes 


Class 

Mnemonics 

oc 

OCX 

Operation 

Special  Procedure 

RETS 

4F 

FE 

Return  with  no  result 

RETSI 

4F 

FD 

Return  with  integer  result 

RETSD 

4F 

FC 

Return  with  double  integer  or  floating  result 

RETSE 

4F 

FB 

Return  with  extended  floating  result 

CALLSF 

4F 

FA 

Call  with  ID  in  register 

GETS1D 

4F 

F9 

Get  re-time  ID  of  function 

Data  Forwarding 

FWD 

4F 

F6 

Forward  integer 

DFWD 

4F 

FS 

Forward  double-precision  integer  or  floating  point 

EFWD 

4F 

F4 

Forward  extended-precision  floating  point 

SYNC 

4F 

F7 

Forward  synchronization  signal 

Semaphore  Instructions 

V 

4F 

FO 

Signal  semaphore 

P 

4F 

FI 

Wait  on  semaphore 

SP 

4F 

EO 

Surrogate  wait  on  semaphore 

CP 

4F 

F3 

Conditional  wait  on  semaphore 

CV 

4F 

F2 

Conditional  signal  semaphore 

Queue  Manipulation  Instructions 

AQ 

4F 

EC 

Add  to  tail  of  queue 

IQ 

4F 

ED 

Insert  after  old  queue  entry 

RQ 

4F 

EE 

Remove  from  head  of  queue 

DQ 

4F 

EF 

Delete  after  old  queue  entry 

CQ 

4F 

El 

Concatenate  queues 

CORDIC  Instructions 

TRIG 

4F 

E3 

Sine,  cosine,  tangent 

ISIN 

4F 

E4 

Arc-sine,  arc -cosine 

IT  AN 

4F 

E5 

Arctangent,  rectangular  to  polar 

HYPE 

4F 

E6 

Hyperbolic  sine,  cosine,  tangent  and  exponential 

IHYP 

4F 

E7 

Inverse  hyperbolic  tangent,  log 

Miscellaneous  Instructions 

EXIT 

4F 

F8 

Exit  task 

EPRI 

4F 

EA 

Equate  priority  of  task 

AR1 

4F 

EB 

Assign  priority  to  task 

SND 

4F 

E2 

Send  message 

RMOV 

4F 

E8 

Remote  move 

TAGM 

4F 

E9 

Tag  memory 

ABSTRACT 


Testability  of  avionics  has  a  direct  impact  on  the  cost  of 
equipment  maintenance.  The  use  of  LSI/VLSI  components  in 
avionics  has  many  advantages  in  terms  of  reliability,  power 
consumtion,  performance,  etc.  Testing  the  hardware,  however,  is 
difficult  because  the  thousands  of  gates  packaged  in  the  LSI/VLSI 
chips  are  physically  inaccessible.  One  solution  to  this  problem 
is  to  provide  new  support  equipment  that  helps  avionics  designers 
and  maintenance  personnel  to  develop  powerful  test  and 
maintenance  programs  capable  of  detecting  and  locating  defective 
components  in  a  cost  effective  manner. 

A  system  comprising  microprocessors  cannot  be  easily  designed 
unless  support  hardware  and  software  such  as  development  systems, 
in-circuit  emulators,  programming  languages,  operating  systems 
are  readily  available.  One  area  in  which  there  is  presently 
very  little  support,  is  testability.  As  a  result,  this  paper 
presents  a  proposal  for  a  support  system  called  in-circuit  fault 
simulator  (ICFS). 

An  in-circuit  fault  simulator  is  a  piece  of  equipment  capable  of 
simulating  technology  dependent  faults  in  a  microprocessor  in 
addition  to  performing  the  function  of  a  fault-free  micro¬ 
processor.  It  is  used  as  support  equipment  in  the  process  of 
developing  test  and  maintenance  software  programs. 

The  paper  presents  the  design,  implementation,  and  utilization 
of  an  ICFS  at  Jet  Propulsion  Laboratory  for  a  microprocessor  used 
in  spacecraft.  The  ICFS  was  first  used  to  develop  test  vectors, 
for  qualifying  the  microprocessor  for  Class  S  applications.  The 
test  vectors  developed  with  the  help  of  the  hardware  fault  simu¬ 
lator  are  running  on  a  commercial  tester  and  are  detecting  99.7$ 
of  the  faults  in  the  microprocessor.  The  second  utilization  of 
the  ICFS  was  in  the  development  of  in-flight  self-test  software 
to  detect  and  locate  the  faults  in  the  flight  hardware. 

In  summary,  this  paper  describes  a  support  system,  called  in- 
circuit  fault  simulator,  for  developing  test  and  maintenance 
software  for  avionics  systems  incorporting  1750A  microprocessors. 
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ABSTRACT 


The  in-circuit  fault  simulator  (ICFS)  described  in  this  paper  is 
a  piece  of  support  equipment  used  to  measure  the  fault  coverage 
of  test  programs  at  component,  board,  and  system  levels.  An  ICFS 
performs  in  real-time  the  same  function  as  a  software  fault 
simulator  running  on  large  computers.  The  ICFS  is  portable,  easy 
to  operate,  and  can  be  used  to  simulate  faults  in  mixed  analog 
and  digital  boards  and  systems. 


1 .  INTRODUCTION 


The  use  of  LSI/VLSI  components  in  avionics  has  many 
advantages  in  terms  of  reliability,  power  comsumption,  and 
performance.  Testing  the  hardware,  however,  is  difficult  because 
the  thousands  of  gates  in  the  LSI/VLSI  devices  are  inaccessible 
for  probing.  A  solution  to  this  problem  is  to  develop  test 
programs  (manually  or  automatically)  and  to  measure  their 
effectiveness  to  detecting  faults  with  a  software  fault 
simulator.  In  practice,  it  has  been  found  that  software  fault 
simulators  have  limitations  in  performing  this  function  for 
boards  and  systems  comprising  LSI/VLSI  components.  Moreover, 
software  fault  simulation  of  mixed  analog  and  digital  boards  or 
systems  is  presently  impractical.  In  order  to  solve  the  problem 
of  fault  simulation  for  a  spacecraft  system  comprising 
microprocessors,  an  in-circuit  fault  simulator  (ICFS)  was 
developed  and  used  under  contract  from  JPL/NASA. 


2.  A  HARDWARE  FAULT  SIMULATOR  FOR  A  GATE 

A  hardware  fault  simulator  for  an  AND  gate  with  primary 
inputs  X  and  Y  is  shown  in  Figure  1.  The  only  faults  necessary 
to  be  injected  are  input  X  3tuck-at-one  (X— 1 ) ,  input  Y  stuck-at- 
one  (Y-1),  and  output  Z  stuck-at-zero  (Z-0).  To  simulate  the 
behavior  of  a  fault-free  two-input  AND  gate,  the  serial-in  and 
parallel-out  auxiliary  shift  register  should  contain  all  "0"s  in 
its  three  shift  register  latches  (SRL1  through  SRL3).  To  simu¬ 
late  X-1,  a  "1"  is  stored  in  SRL1  and  "0"s  are  stored  in  SRL2 
and  SRL3.  As  can  be  seen,  a  "1"  from  SRL1  will  permanently  force 
a  stuck-at-one  at  input  X.  In  the  same  manner,  Y-1  and  Z-0  can 
be  simulated  by  shifting  a  "1"  preceded  and  followed  by  "0"3  in 
the  appropriate  SRL  as  shown  at  the  bottom  of  Figure  1.  An 
implementation  in  CMOS  of  such  a  fault  simulator  for  a  gate, 
called  microsimulator,  is  depicted  in  Figure  2. 


3.  IMPLEMENTATION  OF  AN  IN-CIRCUIT  FAULT  SIMULATOR  (ICFS)  FOR  A 

MICROPROCESSOR 

The  implementation  an  ICFS  for  the  RCA  1802  microprocessor 
was  accomplished  in  two  phases.  In  the  first  phase,  a  breadboard 
that  performs  the  fault-free  function  of  the  RCA  1802  was  built 
using  standard  CMOS  chips.  The  registers  and  the  register  array 
were  implemented  with  MSI  chips  while  the  rest  of  the  micro¬ 
processor  logic  was  implemented  using  only  SSI  chips.  The  fault 
simulation  capability  was  not  provided  in  this  phase  in  order  to 
simplify  the  implementation  of  a  correct  fault-free  system.  In 
the  second  phase,  automatic  fault  injection  capabilities  were 
added  to  the  fault-free  breadboard.  This  was  accomplished  by 


replacing  each  SSI  chip  with  its  corresponding  microsimulator. 
When  all  the  gates  were  replaced  by  the  appropriate  micro¬ 
simulator,  then  the  auxiliary  shift  registers  of  the  microsimu¬ 
lators  were  cascaded,  thus  forming  a  long  shift  register 
comprising  1078  SRLs  (Figure  3).  Therefore,  by  storing  a  "1"  in 
the  appropriate  position  of  the  long  shift  register,  a  particular 
gate  was  selected  and  the  appropriate  fault  was  simulated.  The 
registers  and  the  register  array  were  tested  with  a  checkboard 
test  pattern;  therefore,  no  faults  were  injected  in  them. 


4.  DEVELOPMENT  AND  OPTIMIZATION  OF  TEST  VECTORS  USING  AN  ICFS 

A  test  set  comprising  approximately  13,000  vectors  was  first 
developed  on  a  tester  based  only  on  the  functional  specification 
of  the  microprocessor.  Fault  simulation  was  performed  with  the 
hardware  fault  simulator  plugged  into  the  tester  and  the  fault 
detection  effectiveness  of  the  functional  vectors  was  measured  at 
95%.  At  the  time  of  writing,  only  stuck-at  faults  were 
simulated,  however,  work  is  in  progress  for  simulating  stuck-open 
and  bridging  faults.  Additional  test  vectors  were  developed  for 
the  faults  not  detected  by  the  functional  vectors,  based  on  the 
structural  information  provided  by  the  logic  diagram  of  the 
microprocessor.  From  a  total  of  1078  faults,  eight  were  found  to 
be  undetectable  due  to  logic  redundancies  or  test  sequences  that 
are  impossible  to  generate.  Three  more  faults  may  actually  be 
undetectable;  however,  owing  to  the  difficulty  of  determining 
whether  or  not  they  are  truly  undetectable,  the  worst  case  was 
considered,  and  thus  they  were  classified  as  undetected.  The 
frequency  distribution  of  the  final  fault  simulation  is  shown  in 
Figure  4.  On  the  horizontal  axis  are  listed  the  pattern  numbers, 
while  on  the  vertical  axis  is  the  occurrence  of  detected  faults. 
One  test  pattern  contains  about  1024  vectors.  Most  of  the  faults 
are  detected  for  the  first  time  in  pattern  0,  while  patterns  4 
and  7  detect  very  few  faults  in  the  sequential  and  combinational 
logic;  however,  those  two  patterns  are  directed  toward  testing 
the  registers  and  the  register  array. 

In  summary,  the  final  test  set  contains  14,043  vectors  that 
detect  99.7%  of  the  1070  detectable  single  stuck-at  faults 
injected  in  the  combinational  and  sequential  logic  of  the 
microprocessor.  The  registers  and  register  array  are  fully 
tested  for  single  stuck-at  faults  by  applying  checkerboard  type 
test  vectors. 


5.  DEVELOPMENT  OF  SYSTEM  TEST  AND  DIAGNOSIS  PROGRAMS  WITH  AN 

ICFS 

Test  and  diagnosis  programs  for  boards  and  systems  are 
developed  to  detect  and  locate  faults  in  the  hardware.  A  test 
program  should  detect  a  large  percentage  of  the  faults  in  a  very 
short  time.  An  ICFS  is  used  to  measure  the  fault  coverage  of  a 
test  program  by  simply  replacing  a  microprocessor  device  from  a 
system.  Faults  are  being  injected  automatically  and  the  test 
program  is  run  on  the  system  to  find  whether  or  not  they  are 
detected.  Finally,  the  fault  coverage  of  the  test  program  is 
calculated  by  dividing  the  number  of  faults  detected  by  the  total 
number  of  faults  injected.  Such  a  test  program  was  developed  at 
JPL  with  the  1802  ICFS  for  a  spacecraft.  The  usage  of  the  ICFS 
made  possible  the  optimization  of  the  test  program  -  maximum 
fault  coverage  with  minimum  test  instructions. 

Fault  location  in  the  system  is  also  facilitated  by  the 
ICFS.  During  the  fault  simulation  process,  a  cross  reference 
between  the  test  program  and  the  faults  detected  is  generated. 
This  information  is  used  to  isolate  a  defective  component  either 
by  running  only  the  diagnosis  program  or  by  combining  it  with  a 
guided  probe. 


Experimental  results  with  the  1802  ICFS  show  that  a  test  and 
diagnosis  program  detecting  and  locating  more  than  902  of  the 
faults  in  a  spacecraft  system  resides  in  main  storage  requiring 
about  800  bytes. 


6.  CONCLUSIONS 

An  ICFS  for  a  microprocessor  is  a  cost-effective  testability 
support  piece  of  equipment;  its  feasibility  was  demonstrated  at 
JPL/NASA  for  the  RCA  1802  microprocessor.  An  ICFS  for  the  1750A 
chip,  under  development  by  Fairchild,  can  be  easily  implemented 
with  already  availablle  microsimulators  and  made  available  to  the 
contractors  building  systems  based  on  this  microprocessor  chip. 
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Fig.  1.  A  microsimulator 
for  a  2-input  AND  gate. 
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Fig.  2.  The  implementation  of 
a  microsimulator  in  a  CMOS 
masterslice. 
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Fig.  4.  Frequency  distribution 
of  the  faults  detected  vs. 
pattern  number  for  the  test 
vectors  developed  for  the  RCA 


Fig.  3.  Block  diagram  of  a  physical 
fault  simulator  of  a  microprocessor. 
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SUMMARY  OF  MEASUREMENTS 


(2)  IN  JUNE,  SOME  OF  THE  ORIGINAL  TEST  VECTORS  WERE  MODIFIED 
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EMBEDDED  COMPUTER  STANDARDIZATION  PROGRAM  OFFICE 


-  From  Aug  81  thru  Mar  82  maintenance  support  was  provided  to  the 

ECSPO  by  AFWAL 

— -  AFWAL  contract  transferred  to  ECSPO  1  April  82  and  level  of  con¬ 
tract  increased 

—  A  number  of  compiler  enhancements  are  now  complete  or  nearing  completion 

—  The  translation  of  the  IBM  Compiler  source  from  J73/I  to  J73  was 
completed 

—  The  IBM  code  generator  was  enhanced  with  a  number  of  optimizations 

—  The  IBM  compiler  was  self-compiled 
-  The  DEC-10  compiler  was  self-compiled 

—  Double  precision  Integer/Fixed  point  for  the  1750A  target  is  now 
in  testing  and  should  be  ready  for  release  soon 
■—  A  VAX  rehost  of  the  AFWAL  is  in  progress  with  a  scheduled  completion 
date  of  Sep  82 

-  Compiler  will  have  a  MIL-STD-1750A  code  generator 

—  Compiler  will  be  available  for  test  site  use  in  Oct  82 
—  Compiler  will  be  available  for  full  release  in  spring  of  83 

—  ECSPO  now  supporting  a  number  of  programs  with  maintenance  service 
-  LANTIRN 

-  MATE 

—  Satellite  Control  Facility 
- GPS 

ECSPO  Future  Plans 

—  ECSPO  services  will  improve  and  increase  due  to  additional  manpower 
and  the  direct  contractor  support 

—  Error  status  reports  will  be  available  as  requested  by  the  JOVIAL 


Users  Croup 


—  Error  corrections  will  be  handled  more  responsively 

—  Resources  are  available  for  product  improvements,  attention  will 
be  focused  on  the  1750A  code  generator 

A  VAX  computer  will  be  acquired  to  support  ECSPO  activities 

—  All  configuration  management  will  be  done  on  VAX  computer 

-  VAX  computer  will  be  the  primary  maintenance  system 

» 

—  VAX  will  be  networked  to  IBM  and  DEC-10  systems  for  checkout  of 
those  compilers 

The  ECSPO  plans  to  support  additional  products  as  conditions  warrant  and 
as  resources  permit 

—  The  VAX/1750A  compiler  that  is  currently  under  development 

—  Code  generators  for  other  microprocessors 

— -  Code  generators  are  already  developed  and  maybe  made  available 
to  ECSPO 

-  Compiler  and  1750A  Support  Tools  developed  under  F-16  MSIP 

— -  Current  plans  call  for  ECSPO  to  begin  support  in  FY84  when 
tools  turned  over  to  the  Government 
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Developing  VAX  J73  Compiler  with  1750A  Target 
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AN  IMPLEMENTATION  OF  A  1750  COMPUTER 
AND  ITS  WORKING  ENVIRONMENT 


Israel  E.  Koren 
Chief  of  Computers  Center 
A.E.L.  ISRAEL  Electronics  Industries 
48  Mivtza  Kadesh  st  Bene  Berag,  51203,  Israel 


A.E.L.  Israel  in  response  for  an  RFP  by  IAI  (Israel 
Aircraft  Industries)  c/o  Israel  Air  Force  has  begun  a  develop¬ 
ment  and  implementation  of  a  computer  that  will  emulate  the  1750 
ISA  and  various  tools.  A  compact,  inexpensive  and  portable 
maintenance  and  development  system  LMDS)  and  tools  shall  be 
presented.  Topics  that  shall  be  covered  are: 

a.  Presentation  of  a  1750  computer,  accessories  and 
tools  developed  at  A.E.L.  Israel. 

b.  Software  tools  developed  to  communicate,  monitor  and 
control  1750  computers  and  to  assist  in  development 
and  maintenance  of  military  embedded  computer 
systems . 

c.  Design  ideas  for  special  tools  that  allow  efficient 
integration  of  hardware  with  high  order  language 
software. 


«•  MVT2A  KAOCSH  ST.  BENE  BERAQ  51203  ISRAEL.  TEL.  03-  782141.787131  TWX  03-3553 

U77 


787131 ,782141  To  .VUIT  51203  .,TO '»  48  UTTp  UX30  TTI 


i  ip'WBjp^K  rnroyn  n*jn  t7mKr>  a.ex.  Israel  ltd.  electronics  industries 


I.  INTRODUCTION 

A.E.L.  Israel  is  a  science  based  company  dealing  in  two 
major  areas,  one  is  telephone  switching  and  the  other  is 
military  electronics.  The  military  electronics  is 
divided  into  three  divisions:  Airborne,  Marine  and 
Ground  Forces  Equipment.  The  company  has  over  1000 
employees  of  which  150  are  engineers  and  300  technicians. 

The  Airborne  Division  had  since  1974  experienced  airborne 
EW  with  embedded  computers  which  had  led  the  company  to 
invest  in  a  computer  design  team  that  purchased  a  basic 
computer  production  file  and  developed  it  to  a  product 
which  is  now  installed  on  first  line  aircraft  and  field 
service  ground  equipment  (named  CPLN1 . 

During  1981,  the  airborne  division  had  designed,  built 
and  qualified  a  compact  airborne  computer  to  meet  a 
customer's  specifications  (named  CPLRj .  When  the  IAI  had 
submitted  an  RFP  for  a  1750  computer  the  design  team  had 
found  a  close  match  between  the  CPLR  and  the  requirements 
of  the  MIL-STD ,  the  hardware  architecture  to  perform  the 
standards  ISA  is  already  there  and  by  means  of  micro¬ 
programming,  80%  of  the  1750  ISA  can  be  accomplished. 
The  computer  design  team  is  currently  emulating  these 
instructions  and  at  the  same  time  investigating  the 
needed  hardware  changes  for  complete  implementation.  It 
is  assumed  that  a  complete  1750  computer  will  be  avail¬ 
able  in  the  fourth  quarter  1982. 

II.  A  GENERAL  PURPOSE  AVIONIC  PROCESSOR 

The  GPAP-1750  is  a  family  of  products  that  build  up  a 
General  Purpose  Avionic  Processor.  The  processor  is 
composed  of  a  light  weight  enclosure,  a  variety  of  power 
supplies,  memory  boards  and  peripheral  interfaces.  The 
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CPU  board  comes  in  two  versions,  one  is  implemented  using 
a  chip  set  while  the  other  is  built  around  a  bit  slice. 
The  advantages  of  the  chip  set  will  be  in  lower  power 
consumption  which  leads  to  lower  heat  generated  and 
probably  a  lower  price.  The  bit  slice  advantages  are: 
extreme  speed,  availability  and  most  important, 
flexibility.  The  flexibility  means  that  one  can  extend 
the  instruction  set  of  the  CPU  using  the  BIF  option  of 
the  MIL  STD  at  a  maximum  execution  speed.  The  enclosure 
is  1/2  ATR  short  and  can  be  mounted  on  any  side.  In  the 
proved  CPLN  version  it  dissipates  140  watts  at  full  MIL 
STD  5400  class  II  environment  with  no  forced  air  cooling. 
The  card  cage  holds  eight  boards  10  x  7  inches  with  a  120 
pin  connector  on  its  10  inch  side.  The  bus  is  a  separate 
data/address  bus  and  leaves  the  user  with  about  50  pins 
free.  The  layered  mother  board  is  organized  so  that  the 
user  can  route  signals  to  the  front  panel  on  separate 
layers  so  that  no  interference  can  occur  with  computer 
signals . 

A  Triple  Option  Card  -  TOC,  supports  the  bit  slice  CPU 
board  with  the  discrete  Registers,  Timers,  Trig  Go  and 
Start-Up  PROM.  In  the  chip  set  CPU  all  this  support 
circuitry  will  become  part  of  the  CPU  board. 

The  computed  speed  of  the  GPAP-1750  with  bit  slice  CPU 
and  fast  memory  will  be  652  KOPS  DAIS  MIX.  Power 
consumption  for  a  bit  slice  CPU,  TOC  and  64  K  words  of 
memory  will  be  around  the  25W.  Weight  of  the  above 
configuration  is  about  12  pounds  with  room  for  additional 
five  cards. 
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III.  MAINTENANCE  AND  DEVELOPMENT  STATION  -  MDS 

The  Maintenance  and  Development  Station  is  in  fact  a  1750 
based  computer  whose  computing  performance  is  identical 
to  the  GPAP-1750  computer.  An  MDC  LVL2  or  LVL2E,  the 
versatile  peripheral  equipment  available  and  a  laboratory 
enclosure  turn  this  computer  into  an  easy  to  access  17  50 
computer  for  maintenance  and  development. 

The  MDS  includes  a  general  purpose  power  supply  to  be 
operated  from  220  VAC  50Hz  or  110  VAC  60  Hz.  The  power 
supply  provides  the  following  outputs : 

+5  VDC  at  up  to  35A 
+12  VDC  at  up  to  1.5A 

The  card  cage  in  the  MDS  is  wired  according  to  that  of 
the  GPAP-1750  bus  and  can  occupy  up  to  fourteen  10  x  7 
inch  family-standard  card  assemblies. 

Since  all  card  assemblies  have  standard  connections 
according  to  the  versatile  construction  method,  various 
aspects  of  the  MDS  can  be  emphasized  e.g.  additional 
memory ,  additional  communication  channels ,  etc . 

IV.  MAINTENANCE  AND  DEVELOPMENT  CONSOLE  -  MDC  1750 

The  maintenance  and  development  console  (MDC)  for  the 
GPAP-1750  is  based  upon  means  and  methods  successfully 
developed  and  implemented  in  A.E.L.  Israel  computers. 

The  versatile  MDC  unit  features  a  variety  of  operating 
modes  and  it  is  designed  to  assist  users  of  the  GPAP-1750 
processor  family. 

The  unit  provides  wide  system  support  particularly  in  two 
major  areas,  development  and  maintenance. 

The  MDC  unit  is,  in  fact,  a  small  PDP  11  computer 
station,  connected  to  the  controlled  GPAP-1750  computer 
via  a  special  personality  module  called  Computer  Monitor 
and  Controller  CCMAC) . 
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The  MDC  is  also  designed  to  communicate  and  control  a 
drop-in-board  Real  Time  Bus  Analyzer  (RTBA)  which  is  very 
useful  in  Hardware/Software  integration.  The  MDC  is 
offered  in  two  levels:  LVL2  and  LVL2E .  The  basic 
difference  between  these  two  levels  is  the  type  of 
peripheral  equipment  used  and  the  extent  of  software 
support . 

LVL2  Maintenance  and  Development  Console.  The  system 
includes  a  VT103  computer  terminal  equipped  with  an 
SBC-11/21  computer,  a  64  programmable  Input/Output 
interface  to  control  the  CMAC  and  a  dual  TU58  tape 
cassette  system.  Resident  Soft  Panel  Software  (in  EPROM) 
on  board  the  CPU  enables  the  user  to: 

-  Examine/Deposit  data  in  memory 

-  Examine/Deposit  data  in  General  Registers 

-  Load/Unload  programs  using  tape  cassette 

-  Start/Stop  program  execution 

-  Single-Step  through  program 

-  Set/Clear  Breakpoint  on  any  or  all  of  the 
following  conditions: 

-  Fetch  instruction  from  any  address 
(.including  Read  Only  Memory) 

-  Read/Write  from/to  any  address 

-  Read/Write  any  data 

-  Control  the  Real  Time  Bus  Analyzer  (RTBA) 

-  List/Disassembly  of  memory  area  on  the  VT103 
screen 

-  Be  used  as  a  console  terminal  for  the  computer 
under  test 

LVL2E  Extended  MDC  System.  This  system  is  in  fact  an 
extension  of  the  LVL2  system.  The  difference  between 
these  two  systems  is  in  the  extent  of  software  support 
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and  the  available  extention  using  an  operating  system  and 
a  disk.  The  extended  LVL2E  system  comprises  a  VT103 
computer  terminal  equipped  with  an  LSI,  11-23  CPU,  160 
K  byte  of  RAM,  Dual  TU58  cassette,  10.8  M  byte  Disk,  a  64 
programmable  Input/Output  interface  to  control  the  CMAC 
and  a  IEEE  488  instrumentation  link. 

The  extra  means  of  the  LVL2E  MDC  provides  for  running  the 
following  programs: 

-  File  System  (Disk,  Tape  cassette) 

-  Editors  (.text,  core,  disk) 

-  Cross  assembler  for  the  1750  ISA 

-  Advanced  remote  symbolic  debugger 

V.  COMPUTER  MONITOR  AND  CONTROLLER  -  CMAC 

The  Computer  Monitor  and  Controller  -  CMAC  -  is 
implementation  dependent.  In  the  chip  set  processor  it 
will  be  a  bus  controller  only,  while  in  the  bit  slice 
implementation  it  is  able  to  control  the  internal  CPU 
operation  (_thru  special  micro-code)  .  The  CMAC  is 
actually  an  interface  between  a  remote  console  (or 
computer!  and  the  machine.  It  allows  the  user  to 
establish  a  break  whenever  a  certain  condition  occurs. 
The  CMAC  if  used  plugs  into  the  first  slot  adjacent  to 
the  CPU  card  and  requires  no  special  wiring  on  the  system 
bus.  (There  is  special  wiring  between  slots  1,  2.)  The 
control  signals  to  the  CMAC  are  provided  via  a  connector 
on  top  of  the  card  opposite  the  bus  connector. 

VI.  REAL  TIME  BUS  ANALIZER  -  RTBA 

Real  time  trouble  analysis  in  computer  systems  is  one  of 
the  significant  advantages  of  the  MDS  and  MDC  systems. 
The  RTBA  assembly  enables  trouble  analysis  while  the 
program  is  executed,  without  any  interference  or 
intervention  of  the  test  assembly.  The  RTBA  enables 
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trouble  shooting  while  the  system  is  operating  with  a 
complete  set  of  interrupts  and  DMA.  The  main  functions 
performed  by  the  RTBA  are: 

-  Halting  program  executions  on  one  of  pre¬ 
programmed  conditions, 

-  Displaying  program  flow  before  it  was  halted. 

The  RTBA  is  composed  of  three  main  circuits  mounted  on  a 
single  10  x  7  inch  standard  card  as  follows: 

-  Real  time  data  accumulator 

-  Real  time  equality  detector 

-  Control  analysis  circuits 

The  RTBA  is  controlled  via  the  CMAC  and  the  MDC  or  can  be 
accessed  via  program  control  if  desired. 

VII.  SOFTWARE  TOOLS 

As  a  system  house  A.E.L.  deals  with  various  types  of 
computers,  all  of  them  are  mini's  and  micro's.  The 
experience  with  these  computers  led  to  a  conclusion  to 
equip  the  programmer  with  a  small  station  that  will  allow 
fast  program  editing  compilation  and  debugging  that  is 
the  incentive  of  the  MDC. 

The  MDC  LVL2  system  includes  a  DEC  VT103  computer 
terminal  equipped  with  a  programmable  64  input-output 
interface  to  control  the  CMAC  and  a  TU-58  dual  cassette 
tape  system.  A  special  resident  firmware  called  soft 
panel  within  the  VT103  allows  the  user  to  control  the 
CMAC  as  a  control  panel. 

The  LVL2  MDC  can  be  upgraded  to  a  LVL2E  by  replacing  the 
CPU  adding  memory  and  a  disk  sub  system.  The  operating 
system  can  be  either  RSXll-M  or  UNIX  since  the  supporting 
software  is  written  in  "C"  language. 
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The  supporting  software  includes: 

-  Cross  assembler  for  1750  ISA 

-  Remote  symbolic  debugger 
and  all  features  of  LVL2  MDC, 
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PROPRIETARY  SOFTWARE  SYSTEMS 


LOCATION 


FOUNDED 


Corporate  Headquarters 
in  Los  Angeles 
Offices  in  Seattle  and 
Ventura  County 

October,  1969 
State  of  California 


EXPERTISE  •  JOVIAL  Compilers  (J3,  J73/I,  J73) 

•  Macro/Meta  Assemblers  (DUAL,  etc.) 
e  Link  Editors  (DUAL,  etc.) 

e  Functional  Simulators  (PDP-11, 
NOVA,  INTEL,  MIL- STD  1750A, 

ZILOG,  etc.) 

•  Debug  Tools  (AIDS,  etc.) 
e  Studies:  Ada  Conversion 

Trams ferability 
Compiler  Measurement 
Code  Optimization 

•  Code  Auditors  (RADC,  Boeing) 

•  Support  Software  Tools 
(Editors,  I/O  Handlers, 

Dictionaries,  etc.) 


« 


« 


« 


48* 


PROPRIETARY  SOFTWARE  SYSTEMS 


OUTLINE  OF  PSS  PRESENTATION 


1)  Proprietary  Software  Systems,  Inc. 

A.  Corporate  Background 

B.  Major  Products 

C.  Recent  Contracts 

2)  AFWAL  VAX  Re host 

A.  1750A  Compiler 

B.  Support  Software  Tools  (McDonnell  Douglas) 

3)  General  Dynamics 

A.  1750A  Compiler  Modifications/Enhancements  (AFWAL  1750A  Baseline 

1.  Subroutine  Linkage 

*2 .  Automatic  Allocation 

*3.  Literal  Pools 

*4.  Machine  Specific  Subroutines 

*5.  Symbolic  Debug 

*6.  Sections 

*7.  Base  Register  Emphasis 
*8.  Register  Copy 
*9.  Binary  Operators 
*10.  Fixed  Point 
*11.  Bug  Corrections 

*12.  IEEE  Compatible  Assembly  Listing 
*13.  Subroutine  Register  Save 

B.  DUAL  IEEE  Assembly  Syntax 

1.  IEEE  Syntax 

a)  Base  and  Index  Registers  Enclosed  in  Parentheses 

b)  Extended  Branch  Mnemonics 

c)  IEEE  Mnemonics 

d)  Consistent  Argument  Specification  ( Source -Desti nation ) 

e)  Addressing  Mode  Delimiters 

2 .  DUAL  Features 

a)  Host/Target  Independence 

b)  Extensive  Macro  Facilities 

c)  Minimal  User  Restrictions 

d)  Multiple  Location  Counters 

C.  DUAL  Link  Editor 

1.  User  Controlled  Memory  Allocation 

2.  Overlay  Facilities 

3.  Object  Libraries 

4.  Composite  Listing 

5.  Debug  Facilities 


II 


PROPRIETARY  SOFTWARE  SYSTEMS 


D.  Mil-Std  1750A  Functional  Simulator 

1.  IBM/DEC- 10  Host 

2.  Interactive  Debug  Facilities 

3.  DUAL  Compatibility 

E.  Load  Module  Processor 

1.  General  Dynamics  Compatible  Format 

2 .  Symbolic  Debug  Facilities 

F.  Information  Flow 
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PSS  PRODUCTS/SERVICES 


JOVIAL  (J73) 

PSS  has  in-depth  knowledge  of  the  existing  AFWAL  JOVIAL  (J73) 
1589B  compiler.  Its  staff  includes  the  original  designer  of 
the  code  generator/optimizer  along  with  the  optimizer  imple¬ 
mentor.  PSS  targets  include  the  MECA-43  16  bit,  MECA-43  24 
bit,  the  Delco  M362S,  the  Marconi  920,  and  the  Intel  8086. 
Targets  in  progress  include  the  Mil-Std  1750A,  the  Zilog  Z8001 
and  Zilog  Z8002,  Vax  780,  and  the  CP2-EX. 


DUAL  Meta  Assembler 


DUAL  is  an  easily  retargetable  macro  assembler.  PSS  has 
developed  over  120  cross  assemblers  with  DUAL,  each  including 
DUAL'S  extensive  macro  facility.  DUAL  includes  a  powerful 
linkage  editor  with  numerous  features  designed  specifically 
for  the  aerospace  environment. 


AIDS 

AIDS  provides  a  simplified  method  of  validating  a  program. 
It  runs  either  in  a  simulated  or  actual  mode  and  has  numerous 
debugging  facilities  to  simplify  program  checkout. 
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RECENT  CONTRACTS  (SINCE  1981) 

ARMA  DUAL  Cross  Assembler 

BOEING  Support  Software  for  IUS  project, 

including  JOVIAL  Compiler,  M362S 
assembler,  link  editor,  code  aud¬ 
itor,  and  numerous  utility  tools. 

J73  175 OA  Enhancement  Study 


COOPERS  &  LYBRAND 


Special  Purpose  Language 


GENERAL  DYNAMICS*  JOVIAL  J73  1589B  compiler,  assem- 

.  bier,  link  editor,  and  functional 

simulator  for  Mil-Std  1750A  and 
Zilog  Z8002. 


HAMILTON  STANDARD 


JOVIAL  J73  1589B  Subset  Compiler 
hosted  on  vax  780 


INTEL 


Retargetting  of  JOVIAL  J73  1589B 

compiler  to  Intel  8086 


LOCKHEED 

MOTOROLA* 

NASA 

NORDEN* 


DUAL  Cross  Assembler 


DUAL  Cross 

DUAL  Cross 

JOVIAL  J73 
Z8001. 


Assembler 

Assembler 

1589B  Compiler  to  Zilog 


NTEC 

RADC 

RADC 

SINGER* 

WRIGHT- PATTERSON  AFB 


DUAL  Cross  Assembler 

Code  Auditor  for  JOVIAL  J73  1589B 
Language 

JOVIAL- to- Ada  Translation  Study 

J73  1589B  Compiler  targeted  to  CP2-EX 

Rehost  of  JOVIAL  J73  1589B  compiler 
to  VAX  780 


*  Indicates  technical  effort  still  in  progress. 
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DEC- 10  Host  with  VAX  780  Target1 


Retargetting  DEC-10  AFWAL  J73  compiler  to  generate 
VAX  780  macro  assembly  source. 

VAX  780  Host  with  VAX  780  Target 

Operational  VAX  780  JOVIAL  J73  compiler  operating 
under  VMS  operating  system. 


VAX  780  Host  with  1750A  Support  Software 

Rehosting  existing  AFWAL  1750A  code  generator  to 
VAX  780  system  interfacing  with  1750A  target^  Vali¬ 
dating  the  AFWAL  compiler's  interface  with  the  re¬ 
hosted  McDonnell  Douglas  1750A  support  tools. 
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GENERAL  DYNAMICS  AFWAL  J73  COMPILER  MODIFICATIONS /ENHANCEMENTS 

•  Subroutine  Linkage  (Passing  arguments  in  registers) 

Modifying  existing  technology  to  pass  arguments  in  registers. 

•  Automatic  Allocation 

Current  AFWAL  compiler  allocates  local  automatic  data  and 
local  temporaries  statically  and  also  assigns  a  base  register 
to  cover  this  data  region.  PSS  has  modified  this  allocation 
to  allocate  local  automatic  data  and  temporaries  .on  a  dynamic 
stack. 

•  Literal  Pools 

Current  AFWAL  compiler  allocates  literals  on  a  module  by  mod¬ 
ule  basis.  PSS  modification  pools  all  literals  at  link  time, 
thus  assuring  only  one  copy  of  each  literal.  This  includes 
partial  literals. 

•  Machine  Specific  Subroutines 

PSS  has  modified  the  AFWAL  compiler  to  automatically  recognize 
a  set  of  1750A  specific  functions  in  order  to  facilitate 
generation  of  efficient  1750A  instructions. 

These  machine  specific  functions  include: 

ROTATE 
EXEC' CALL 
MOV' DATA 
OUTPUT 
INPUT 

CARRY' FLAG 

•  Symbolic  Debug 

The  compiler  object  module  now  includes  symbolic  information  to 
support  simplified  debug  of  175 OA  J73  JOVIAL  programs. 

•  User  Controlled  Allocation 

The  AFWAL  compiler  has  been  modified  to  include  a  separation  of 
each  compilation  unit  into  four  distinct  sections.  Each  of 
these  sections  has  a  section  number  associated  with  it  and  can 
be  modified  by  the  user  to  control  allocation.  The  sections  are 
CODE,  DATA,  CONS  and  LPOOL. 

•  Base  Register  Emphasis 

PSS  has  made  significant  modifications  to  the  AFWAL  code 
generator  addressing  logic  so  that  it  emphasizes  base  register 
addressing  (short  instructions) . 
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COMPILER  MODIFICATIONS/ENHANCEMENTS 
(CONTINUED) 


•  Specific  Optimizations 

Several  target  specific  optimizations  have  been  made 
to  minimize  the  amount  of  code  being  generated (mini¬ 
mize  unnecessary  register  copies,  pushing  and  popping 
only  required  registers  on  subroutine  entry  and 
exit,  fixed  point  operations  to  generate  inline  aode, 
special  logic  to  minimize  binary  code  generation 
when  one  of  the  arguments  is  a  short  immediate,  etc.) 


•  IEEE  Assembly  Syntax  Capability 

Assembly  listing  reflects  new  1750A  IEEE  assembly 
syntax. 


•  Bug  Corrections 

Correction  of  any  known  1750A  code  generator  prob¬ 
lems. 


PSS  JOVIAL  J73  1589B  I750A  SUPPORT  SOFTWARE  PROJECTS 


AFWAL  VAX  Rehost 

Existing  1750A  compiler  and  McDonnell  Douglas  support 
software  hosted  on  VAX  780  for  WPAFB. 


General  Dynamics 

Modified/Enhanced  1750A  compiler  with  new  support  soft¬ 
ware  hosted  on  IBM  370.  Part  of  General  Dynamics  F-16 
flight  improvement  program. 


Boeing 

Modified/Enhanced  1750A  JOVIAL  J73  compiler  coupled  with 
Boeing  support  software  hosted  on  IBM  370.  Part  of  Boeing 
B-1B  program. 


Base  and  Index  Registers  enclosed  in  parenthe 

OLD  IEEE 

LD  1 , OMEGA , 5  LD  Rl , OMEGA (R5) 

Register  Mnemonics  Must  Be  Used 

R0-R15 

RL0-RL7 

RH0-RH7 

RR0-RR14 

RQ0-RQ12 

IEEE  Mnemonics  1 

Consistent  Argument  Specification 
Always  SOURCE, DESTINATION 

Addressing  Mode  Delimiters 

@ . Indirect 

# . Short  Immediate 

## . Long  Immediate 

+ . Auto  Increment 

- . Auto  Decrement 

% . Relative  Addressing 


GENERAL  DYNAMICS  DUAL  MIL- STD  1750A  CROSS  ASSEMBLER 


DUAL  Features 

•  Host  Machine  Independence 

Operational  on  22  different  hosts  including  the  IBM 
370,  DEC-10,  VAX  780,  Univac  1100,  Honeywell  6000, 
CDC  6000,  Interdata  7/32,  etc. 

•  Target  Machine  Independence 

Over  120  cross  assemblers  by  PSS  and  its  customers, 
including  numerous  built-in  cross  assemblers (1750A, 
PDP-11,  Intel  8080,  Data  General  NOVA,  Zilog  Z8001, 
Zilog  Z8002,  Motorola  6800,  etc.) 

•  Extensive  Macro  Facilities 

Extremely  powerful  directives  and  functions  facili¬ 
tating  macro  implementation.  Features  include  user 
definable  symbol  table,  numerous  character  manipu¬ 
lation  functions,  conditional  directives,  macro 
libraries,  etc.  DUAL  contains  over  120  directives 
and  50  functions. 

•  Minimal  User  Restrictions 

No  limit  to  number  characters  in  a  name,  number  of 
macros,  etc. 

•  Multiple  Location  Counters 

Each  assembly  unit  can  contain  up  to  32  distinct 
location  counters.  DUAL  supports  CSECTS,  DSECTS, 
and  FORTRAN  common. 
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•  Base  and  Index  Registers  enclosed  in  parentheses 

OLD  IEEE 

LD  1 , OMEGA , 5  LD  Rl , OMEGA (R5) 


•  Register  Mnemonics  Must  Be  Used 

R0-R15 

RL0-RL7 

RH0-RH7 

RR0-RR14 

RQ0-RQ12 

•  IEEE  Mnemonics 


•  Consistent  Argument  Specification 
Always  SOURCE, DESTINATION 

•  Addressing  Mode  Delimiters 


@ . Indirect 

# . Short  Immediate 

## . Long  Immediate 

+ . Auto  Increment 

- . Auto  Decrement 

% . Relative  Addressing 


GENERAL  DYNAMICS  DUAL  MIL-STD  1750A  LINK  EDITOR 


Link  Editor  Features 

•  User  Controlled  Memory  Allocation 

User  can  specify  whether  modules  are  to  be  contiguous  or 
whether  sections  are  to  be  contiguous,  thus  potentially 
separating  J73  CODE,  CONS  and  DATA  into  unique  memory 
sections. 

•  Overlay  Facilities 

Link  Editor  supports  overlays  via  OVERLAY  command  or 
FORTRAN  common. 

•  Object  Libraries 

Link  Editor  (if  option  chosen)  will  automatically  search 
object  library  to  satisfy  any  undefined  externals.  Link 
editor  also  includes  IGNORE  and  INCLUDE  commands. 

•  Composite  Listing 

If  user  passes  source  in  DUAL  assemblies  (LIST),  then,  the 
link  editor  on  option  (LIST)  will  generate  a  composite 
absolute  assembly  listing  for  all  the  included  object 
modules. 

•  Debug  Facilities 

Link  Editor  generates  a  file  containing  all  addresses  of 
symbols  on  a  module  by  module  basis  to  be  used  by  a 
debugger . 


GENERAL  DYNAMICS  MIL-STD  1750A  SUPPORT  TOOLS 


Functional  Simulator 

•  IBM  370  or  DEC-10  Host 

•  Interactive  Debug  Facilities 

•  DUAL  Compatibility 

•  Tool  used  for  JCVS  Testing 


Load  Module  Processor 

•  Outputs  General  Dynamics  Compatible  Format 

•  Generates  Separate  Symbolic  Debug  File 

•  Checksum  Facility 


GENERAL  DYNAMICS  MIL- STD  1750A  SUPPORT  SOFTWARE  INFORMATION  FLOW 


JOVIAL  J73  1589 
COMPILER  FOR 

IBM  370  HOST 


-►Ilisting) 

(LIBRARY 

\FILE J 

DUAL  MIL- STD 
175 0A  CROSS 
ASSEMBLER  ON 
IBM  370  HOST 


NEW\ 

"^SOURCE] 


^GENERAL  DYNAMICS'' 
FORMATTED  LOAD 
^  MODULE  J 


F-16 


MIL-STD  1750A 

MIL-STD  1750A 

HOST 

ABSOLUTE  LOADER 
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USE  OF  THE  1750A  SUPPORT  SOFTWARE  ON  AN  IBM  3033  UNDER  MV/CMS 

John  Riordan 

Mikros  Systems  Corporation 
Mercerville,  New  Jersey  08619 


ABSTRACT 

The  McDonnell  Douglas  Support  Software  package  is  configur 
ed  to  run  on  a  DEC-10  system  and  an  IBM  system  running  TSO. 
Since  the  time-sharing  system  available  at  Mikros  was  IBM's 
VM/CMS,  a  conversion  of  the  supplied  control  language  was  under 
taken.  Details  of  this  conversion  are  given. 

Simulator  10  routines  were  written  to  permit  interactive 
use  of  a  1750A  cross-assembled  program  executing  through  the 
simulator.  Examples  of  the  control  language  and  10  routines 
developed  will  be  included. 

INTRODUCTION 

The  MIL-STD-1750A  Support  Software  Package  was  developed 
at  McDonnell  Douglas  under  contract  to  the  USAF.  The  Package 
provides  a  complete  set  of  software  development  tools  for  1750A 
assembly  language  programming,  including  a  Macropreprocessor 
(MPP) ,  Assembler  (MSA) ,  Linker  (MSL) ,  Simulator  (MSS)  and 
utilities  for  library  maintenance  and  reformatting. 

The  Package  is  available  from  ASD  at  Wright  Patterson 
AFB ,  and  is  distributed  for  use  on  an  IBM  TSO  system,  or  on 
DEC  10  and  VAX  11/780.  This  paper  describes  the  installation 
of  the  Support  Software  Package  on  the  Princeton  University 
IBM  3033  system  under  VM/CMS  timesharing. 


The  tape  supplied  contains  27  files  for  the  installation, 
testing  and  use  of  the  support  system  under  IBM's  TSO.  For  a 
CMS  system,  the  following  procedures  must  be  followed: 

a)  source  code  files  are  copied  from  the  tape  and 
made  into  proper  FORTRAN  or  ASSEMBLE  files 

b)  test  cases  are  copied  and  named  as  required  by  the 
CMS  control  language 

c)  CLIST  files  are  not  copied.  The  equivalent  CMS 
EXEC's  must  be  written 

d)  the  HELP  and  ERROR  files  are  copied  and  named  as 
required 

Each  program  provided  must  be  compiled  or  assembled,  (added 
to  a  TXTLIB,  if  applicable) ,  LOADed,  and  GENMODed.  The  program 
will  then  be  executable  (as  a  module) .  The  proper  EXEC  will  be 
used  to  specify  parameters,  to  allocate  files  and  to  start 
execution. 

In  order  to  describe  the  use  of  the  system  as  configured  at 
MIKROS,  the  following  convention  must  be  detailed: 

o  Files  have  three  descriptors  -  filename,  filetype, 
filemode  (this  is  a  CMS  convention) 

o  In  all  EXEC's  used  for  running  the  support  system, 
the  following  are  assumed: 


Filename  Filetype _ Filemode _ Use 


any 

MACROLIB 

A 

Macro  Library 

any 

MACDEF 

A 

Macro  Definition 

any 

LISTSML 

A 

Library  Update  Listing 

any 

SOURCE 

A 

1750A  Source  Pgm. 

any 

LISTMPP 

A 

MPP  Listing 

any 

ASM1750 

A 

1750  Assembler  Code 
(output  of  pre-pro¬ 
cessor) 

any 

OBJ1750 

A 

Object  file  (output 
of  Assembler) 

any 

LISTMSA 

A 

Assembly  Listing 

any 

DIRECTIV 

A 

Linkage  Editor  Comm¬ 
ands 

any 

MAP 

A 

Linkage  Editor  Map 

any 

ABS1750 

A 

Absolute  Module  (out¬ 
put  of  Link  Editor) 

any 

MOD1750 

A 

Load  Module  (output 
of  Reformatter) 

any 

SYM1750 

A 

Symbol  Table  (output 
of  Reformatter) 

502 


The  EXEC’s  used  (in  the  included  listing)  are  named: 


SML  EXEC 
MPP  EXEC 
MSA  EXEC 
MSAX  EXEC 
MSL  EXEC 
MSLX  EXEC 
MSS  EXEC 
MSSX  EXEC 
ALR  EXEC 


System  Macro  Library  Manager 

Pre-Processor 

Assembler 

Assembler  (without  prompting) 
Linkage  Editor 

Linkage  Editor  (without  prompting) 
Simulator 

Simulator  (without  prompting) 
Executes  EXEC's,  MSA,  MSL,  and  MSS 


SIMULATOR  FLOW  CHART 


Old 

L 1 brary 
fnsm*  flACR OLJB 


Ntw  Macro  Naw  ,  ,  Mow  Axanolor 

Doflnltton  Library  j  Cod* 

foam*  MACCCf  fnan*  nACROLIB  ( f non*  SOURCE) 


USE  OF  FILES  ON  SUPPLIED  TAPE 


File  No. 


New  Names 


JCL  to  copy  files  on  to  TSO 
QSHIFT  Assembler  Prog. 

CORE 

IUNPAK  FORTRAN  Prog. 

QCONV  FORTRAN  Prog. 

SECOND  FORTRAN  Prog. 

System  Macro  Library 
Manager  -  SML 
Pre  Processor  -  MPP 
Hash  Table  Prog. 

Input  to  Hash 
Assembler  -  MSA 
Linkage  Editor  -  MSL 
Reformatter  -  RFMT 
Assembler  Routine 
(necessary  for  Simulator) 
Simulator  -  MSS 
Help  File 
Error  File 
Test  Case  for  SML 
MPP 
MSA 
MSL 
MSS 

TSO  Proc's  for  SML 


Delete 

Assemble,  Com¬ 
pile.  Add  to 
SIMULIB 

SML  FORTRAN 

MPP  FORTRAN 
Output  is 
ASM1750  INI  A4 
MSA  FORTRAN 
MSL  FORTRAN 
RFMT  FORTRAN 
Assembler,  Add 
to  SIMULIB 
MSS1* • • 7  FORTRAN 
PEKHLP  HELP 
PEKERR  HELP 


Used  these  files 
to  test  Simulator 


Delete 


INPUT/OUTPUT  FOR  17 50 A  SIMULATOR 


To  simulate  the  I/O  processes  using  the  XIO  PI/PO  and  CI/CO 
instructions,  the  following  assumptions  are  made: 


1) 


2) 


3) 


4) 


The  PI/PO  instructions  read  and  write  from  a  channel 
number  encoded  into  the  instruction.  This  number 
(0-3)  is  the  'y'  of  the  specification.  The  'xx' 
of  the  specification  is  disregarded. 

The  channel  FORTRAN  Unit  No.  correspondence  is: 


( 

channel  0  Unit 

20 

PI  ( 

1 

21 

( 

2 

22 

( 

3 

23 

Cl  ( 

4 

24 

( 

0 

30 

PO  ( 

1 

31 

( 

2 

32 

( 

3 

33 

CO  ( 

4 

34 

(Note : 

In  code  CHNLNO  = 

Channel  No 

correspondence  is  set  in  the  initialization  of  the 
labeled  COMMON  "QUNITS" . 


The  (Carriage  Return)  character  is  not  a  valid  1750A 
input/output  character.  This  limitation  results 
from  the  fact  that  FORTRAN  demands  we  read  a  record 
at  a  time,  not  a  character  at  a  time.  Therefore,  the 
(CR)  serves  as  the  end-of-record  delimiter. 

The  channel  buffer  sizes  are  set  in  the  dimensioning 
of  the  labeled  COMMON  " IOHAND" . 


Note:  The  large  source  program  files  are  too  big  to  edit  on  CMS 

in  the  maximum  virtual  machine  size  available  to  us.  To 
make  the  changes  necessary  in  the  Simulator,  the  MSS 
source  program  was  divided  into  six  subset  files,  using 
the  GETFILE  CMS  command.  Changes  to  the  program's  COMMON 
must  be  made  in  each  routine,  along  with  code  changes 
made  to  IN  and  OUT's  COMMON,  and  the  code  necessary  to 
implement  the  10  are  shown  in  the  accompanying  listing. 


rt  System 


S  M  L 


EXEC 


ICONTROL  ERROR 

iTYPE  SYSTEM  MACRO  LIBRARY  MANAGER  -  S  M  L 

*  EXEC  created  i  1-03-9'  BY  John  Riordan  OF  MIKRQS  Svt 

-TYPE  NOTE:  •=  CR>  in  proisoLs  -a  i  o  n  i  *  i  e  «  cirriioo 
rI  *  CLEAR 

•4"Y=  E  INPUT  DATA  FILE  NAME? 

IREAD  VARS  tIN»UT 

.SINPUT  -  .  IGOTO  -STAR1 

FI  1  DISK  1INPUT  MACDEF  _  -  ...... 

230T0  -NXT1 
-STAR1 

FI  1.  TERMINAL.  ...  . .  .....  ...  .  .... 

* 

-NXT1 

ITYPE  Listina  data  File  name  NAME  <  or  <CR>  for  terminal)? 

IREAD  VARS  ILIST 

IIP  .  ILIST  =  .  IGOTO  -ST ARC 

"12  DISK  ILIST  LISTSML  A  CRECFM  FBA  LRECL  SO  BLKSI'ZE  800 
IGOTO  -NXT2 
-STAR2 

FI  2  TERMINAL 

* 

-NXT2 

FI  S  TERMINAL  .  ~  "*  . . . . . . . 

FI  6  TERMINAL 

ITYPE  Old  Macro  Library  file  neme? 

IREAD  VARS  I0LDLIB 

ITYPE  New  Macro  Library  file  name7 
IREAD  VARS  INEWLIB 

i:f  . soldlib  =  .  igotc  -nold 

FI  3  DISK  INEWLIB  MACROLIB  A  < RECFM  VBS  LRECL  516  BLKSIZE  2504 
IGOTO  -NXT3 

-NOLD 

F  ?  3  DISK  SNEWLIB  macro:.  IB  A  .LRHC:  Z'6  RFCFM  VBS  BLKSIZE  358* 


SI'  . I INPUT  *  .  ITY^E  SKL  AWAITING  TITL'Tsi 
SMI. 

i-~  . &0LDLIB  «  .  SEX:^ 

ITF  IOLDuIB  1NEWL.  t Z  SGC*"  •LEX 
Z~  *  ?  E  TEMP3ZC  MACRQL  *3 
IE/  IT 

* 

-REN 

IIF  IRETCODE  >  0  IEXIT 

ERASE  SOLDLIE  MACROLIB  A  •:  NOTY-  E 

RENAME  TEMPO ?0  MACROLIB  A  sGi.DLVB  MACROLIB  A  (NOTYPE 
i  EX  IT 


T-0.01/0.09  10:31:5* 


F 1 1_£ :  mpp- 


tlXi_  c 


PKi.MCfc.TUN  uNWcHilTY  T  IME— SHARING  ST 


*  M  -»  P  £  X  E  C 

* 

SCUM  TRUl  &kRlk 

STYPE  MACRO  PRS  PROCESS  —  N  P  P 

*  CREATES  ASScMbcER  INPUT  KIlE  rKUM 

*  SOURCE  CJOE  F  ll_2  » 

*  CKC-ATbU  ll-3-ol  BT  JOHN  RIUWOAN  UK  MlKKUS  SYSTEMS  CuRP. 

* 

FI  *  C1_£AR 

Ft  23-  OtS*C  TEMP23  QRARY  A  (LKcCL  30  RECFM  FEi  aLKSl  2E  300 

s. Type  input  source  f ice  name? 

GREAD  VARS  t  INPUT 

SI F  • S IN  PUT  =  •  oGOTO  -JMP1 

FI  5  DISK  S  INPUT  SOURCE  A  ( LRE  CL.  SO  RECFM  FB  bLXSIXE  800 
SGOTCJ  — NXT 1 
-JWM 

FI  S  TERMINAL 

•  *  - 

-NXT  1 

6TYP;  LIsTInG  FILE  NAME? 

SREAU  VaRS  glist 

cif  *.eLisT  =  «  scut  a  — jmp2 

FI  6.  DISK.  SC.  1ST  lISTMPP  A  ClReCL  137  RECFM  VoA  3LKSIZE  1AIA 

_  GGOTO  -NXT2 

-J4P2 

FI  o  TERMINAL 

♦ 

-NXT2 

GTYP£  OUTPUT  FI uE  NAME? 

SREAD  VARS  SPUN 

S1F  •  <fPUN  =  «  sCuTU  — JMP3 

FI  3  BISK  SPUN  ASAWbO  A  (RECFM  Fb  ukECL  bO  BLKsIEE  300 
SC  UT u  —NX  r 3 
-JMP3 

FI  3  TERMINAL 

* 

-nx  r  3 

ST  YPc  MACRO  HbKARY  FILE  NAME  (KCKP  IF  NUT  uSEO)? 

SHEAU  VARS  SlI  3 

fclF  « sLI B  =  «  SCOT a  -REST 

FI  2A  DISK  SUb  MACRULI3  AA  (LRECL  5lo  HEC  FA  V8S  BLKSIEE  238* 

* 

-REST 

SIF  .  SlNPUT  =  .  STY  Pd  MPP  AAAI  T  I  NG  INPUT 

* 

MPP 

SIF  S  RET  CODE  >  O  SEX  IT 
ERASE  TE.VP23  CRaRY 


SfcXlT 


5  09 


Flu: 


EA^C 


PR  INCLTUN  oNlVcKbMY  T  IMe-SHAKlNG  SVi 


i£  A  £  C 


^CONTROL  ERROR 

GTy»t_  cross  asS£.mo4_r  -  m  s  a 

*  PRODUCES  AN  CBJtCr  PILE  FRUM  AN 

*  CREATED  11-3-31  oY  JOHN  rioruan 


AS  sEMSUiR 
OF  MlKKUS 


CODE  PROGRAM 
SYSTEMS  CUKP. 


Fi  ♦  CLEAR 

FI  t  Oi-SK  TEMPT  UKAkY  Am-  CRECFM  WsS-  UtCt  SU 

Ft  2:  DISK  TEMPS  CHARY  A*  {RECFM  V8s  LftECt  516 

FI  3-  DISK  TEMP3  ORAR  Y  A4  IRECFiM  VBS  LRECC  SI  6 

FT  A-  DISK  TEMPA  URARY  AA  4RECFM  VBS  LRECL  SI 6 

FI  5  TERM  1 NAl 
FI  6  TERMINAL 


si.KE.IAE  AsUA 
BUASI2E  £604 
3LKS12E  2604 
sLKSlZE  260  4 


GTYPE  INPUT  SOURCE  FILE  NAME  i  <CR>  FOR  TERMINAL.)? 

&READ  VARS  &  INPUT 

---  SIP  .GINPUT  -  ,  6601  U  —TERM  i  ^  Pi 

FI  1C‘  DISK  <,  INPUT  ASMI7SO  A  t  R  ECFM  FB  LkcCL  SO  SLKslZE  sOO 
&6UTU  — NXT2 

-TEKMl . .  . ... — .... _ .......  _ 

Pi  io-  terninac 

m  '  _ 

-*t*T2 

GTYP^  LISTING  Data  FILE  name  < <CH>  for  TERMINAL)? 

LKEAD  VARS  DlIsT 

lIF  »GL 1st  &  ,  GoOTu  ~tEWM2 

FI  11  DISK  GLIST  LISTMSa  A  IReCFM  VBA  LkECL  137  BLKS12E  14IA 
GGUTO  — N  XT  3 
-TER  M2 

FI  11  TERMINAL 

* 

-NXT  J. 

GTYP^  OUTPUT  03JECT  FILE  NAME  4  REGUI  RED  )  ? 

GREAD  VARS  GUBJ 

SIP  .LUOS  =.  *  SOU l U  -ERR  UK 

Fi  lj  DISK  GOOM  OuJl  7S0  mA  4  RECF  M  VbS  LreCL  1  02  J  si-KSIit  SIAM 
FI  12  DISK  T  i  MR  1 2  QKaRY  AA  (  RECFM  VUG  i_r£CL  102E  .iLKSIZC  sIaa 
FI  S  Ui.SK  ASM1/S0  INI  AM  4.RECF.M  Vt>S  LRC-Ct-  2*000  SLKSlEE  c.  *000 
GIF  .&INPUT  *  .  6TYP&  MSA  AWAITING  INPUT 


GIF  * GL I  ST  =  .  GSXIT 

GTYPE  YOUR  AssfcMsuE  LlSliNG  LS  UN  "  sL  1ST  uiSTMBA" 
GTYPE  TO  PRINT  LISTING,-  TYPE  "TYPE130  GLIST  LISTMSA- 


GTYPE  TO  PRINT  LI 
erase  Tempi  uRaky 
ERASE  TEMP  2  UKARY 
ER  ASc.  TEMP  3  UHARY 
SHASl.  Tt  MP4  URAxY 
scXIT 


(  NU  r  THE 
4  NU  r  YPE 
(NOT  rPt 
(NU  r  YPE 


— £ KHOH 

GTYPE  SORRY,  UoJtCl  FILE  NAM  c  IS  REUuIrEo 


510 


FILe.1  MSAX 


cXcC 


A 


PRINCETON  UNlVcft^TY  I  iME-SriARlNG  ;>Y  . 


* 

*  M  S  a  X  E  A  t  C 

* 

SCONTruL  OFF 

ctypl  cR^ss  as6HM3lr  -  m  >  a 

♦  PRODUCES  AN  OBJECT  FILE  FROM  AN  ASSEMBLER  CODE  PkUORAM. 

*-  This  version  permits  executing  mith  cn=  inpui  name  parameter. 

♦  AND  NW  PHuMPTINu.  T  i-iE  F1i_E  NAHci  larilCri  MUST  at  COMMON  HJk 

♦  ALL.  THE  FIi_£S>  ARE  s£  T  *Ht~  N  THE  EXEC  IS  EXtCUTEDI 

«.  MSAX  F NAME  ►  «HERE  FNAME  Id-  Trie  COMMON  NAME » 

♦  THIS  EXEC  *AS  CREATED  12-7-6  L  iir  JOMN  R IORDAN  OF  MIKROS  SYSTEMS 

♦ 

MF  >C-1  -  .  6-CiOTO  -NUAMPER 
FI  *  CL=-AR 

FI  1  DISK  TEMPI  ORARY  A4  IRECFm  vBS  LRECl  si  6  ULKSlZfc  2604 

FI  2  DISK-  TEMP2  ORARY  A4  (rECFM  VOS  LRECL  Sio  BLKS1ZE  260  4 

FI  3  DISK  TEMP3  ORARY  A4-  £R£CFM  VBS  LRECL  516  8LKSIZE  260  4 

FI  A  DISK  TEMP*  URARY  A4  IRSCFM  VBS  LRECL  Si  6  ULKSIZE  2604 

FI  S  TERMINAL 
FI  t>  TERMINAL 

* 

FI  la  DISK.  EL  \SML75a  A-  CRE-CFM.  F3  LRECL-  60  BCKSlZt-  800 
FI  IL  DISK  61  uISTMSA  A  tR£CF*f  VBA  LRE  CL  137  SLKS1 ZE  1414 
FI  13  DISK  6-1  OOJIZSO  A4-  IRECF*  VBS-  LRECL  ID2M  dLKSlZE  S144 
FI  12  DISK  TEMP12  OR  ARY  A4  IrECFM  VttS  LKfcCL  102d  8LKSIZE  SI44 
FI  8  DISK  ASM I  75 O  INI  A4  (RECFM  VaS  i_Re.CE  24000  oLa^IZE  £«UUO 
MSA 

• 

61 F  6RETCCDE  >  O  Sf  X  IT 

6TYPE  YOUR  ASSEMBLE  LISTING  IS  UN  -  &i  LiSTMSA- 
CTYPfc  TO  PRINT  LIST  I  NS.  TYPES  "TYPtI30  tl  L I S 1 MSA" 

ERASE  TEMPI  URARY  A 
ERAoE  TE.MP2  ORAhY  a 
ERaSC  TEMPO  LRARY  A 
ERASE  TEMP  4  OR  ARY  A 
ERASE  TEMP 12  UR ARY  A 
6EX1  r 

* 

-NGAMPEk 

6TYPE  yuU  FUHGET  THE  FILL  NaMLS. 

6TYPE  DON*T  GET  NERVOUS*  TRY  AGAIN 


u 


Flt_£  i  RBL 


RRINCEluN  UNIVERSITY  I|ME-SliAKl.Mt>  SY 


GTYpE  REFORMAT  PROGRAM  -  R  F  M  T 
*-  CREATES  A  LOAD  MODULE  AND  A  SYMBOL  TABLE 

*  FWU  M  AN  ABSOLUTE  FILE. 

* 

uTYPc  OUTPUT  LOAD  MUUULE  F 1  l_E  name  IKCUJUcbt? 

GREaD  VARS  GLDM 

GIF  .GLDM  =  ■  GtiOTQ  —ERR OH 

* 

*  tTYPfc  OUTPUT  aYMBOL  TABLE  Fii_c  NAMc  (ktUUJRtU)? 

*  GREAD  VARS  GSYM 

*  GIF’  * GSY M  —  *.  LOOT  U-  — E  RRUR2.  .  

*  '  •'•!.-•  r.:  -- 

FI  9  TERMINAL 

FT  i  DISK  GLOW  MuOI7SO  A  (HECFM  FB  LRE  CL  SO  SLK-Sl^fc  BOO 
»  Kl  4  DISK  GsYM  SYM17SO  A  (RECFM  F  LRcCl  10E**  dUSUt  102*  OSURo  DA 
FI  A  DUMMY 

FI  0.  DISK.  GABS  A3aWBO  Am.  CRSCFM  VSS  LrtECL  lOOS  BLKbIZE  SIAM 

*■ 

*  note:  a  load  OF  THE  TEXT  File  is  used  here  instead  uf 

*•  THE  EXECUTION  UF  A  MOGUL'S  BECAUSE  THE  MUOULE 

*  SEEMS  TO  LOAD  FUNNY  AND  CAUSES  ER KURS •  I  DON • T  K NOW  4HY 

LOAD  RFMT  (CLEAR  START 

*  RFMT  . .  ..  _  7 _  .  . 

GIF  GRETCQOE  >  O  GEXIT 
ERASE  TEMPS  OR ARY  A 
ERASE  TEMPS  UNARY  A 
ERABt  TEMP/  OkARY  A 
ERASE  Tb  MP3  OHARY  A 
GEX1  T 
A 

-ERRUR2 

GlYPE  •  REQUIRED  *  MEANS  "WITHOUT  WHICH.  NOTHIN*,"  J 
GT YPi  Try  a^in 
(.EXIT  1 
GEXIT 


—ERR  UR 

gtype  surry.  absolute  file  name  is  rEuuired 


GTYPE  GUO  Do  YE*  try  AGAIN 
G£  A  IT 


fils:  msl 


EXEC 


A 


PRiNCfcTUN  UNIVERSITY  rHll-SHAHlNb  SY‘ 


►l 


*  M  s  L  2  X  £  C 

* 

DLONTRUL  £  kRUR 
FI  *  CLEAR 

DTYPE  LINKAGE  EDITOR  -  MSL 

*  PRODUCES  ABSOLUTE  FILE  FROM  ubJECT  FILE. 

*  (.RliATiO  il-3-ei  df  JOHN  RIO  HD  AN  or  MIKRU3  3Y3T=MS  ljKP. 


DTYPE  DIRECTIVE  FILE  NAME  ( <CK>  FOR  TERMINAL 

DREAD  VARS  DO  IR 

DlF  *DDIR  =  *  DGUTO  -TERM! 

FI  L  DISK.  DDlR  dIRFCTIV  A  I RgCFM  F  LwECL  80 
DoOTu  -JMP1 


—  TERM  1 

FI  1  TERMINAL 


1  ? 


— JMP  1 

DTYPE.  MAP  FILE  name  (<CR>  FOR  TERMINAL  i 

DREAD  VARS  DMAP 

DIF  .DMAP  =  •  DGUTO  -TERM2 

FI  2.  DISK  DMAP  MAP  A  ILRECL  30  RECFM  FoA  3LKS12E  300 
DGOTO  — JMP2 
—TERM  2^ 

_  FI  2.  terminal 
* 

-JMP2 

dtype  ao solute  file  name  (keuuiredi? 

DREAD  VARS  DABS 

DIF  .DA3S  *  *  DGOTO  -ERROR 

FI  3.  DISK  DABS  AuS17bO  AD  ILRECL  1023  RECFM  VBS  6LKSIZS  5  1  A* 


FI 

S 

O  1  SK 

TEMPS 

ORAR  Y 

AM 

( LRcCL 

Sic 

RECFM 

VBS 

jlkS  Lc 

253  a 

FI 

6 

DISK 

temps 

ORARY 

Aa 

CLRECl 

51  o 

RECFM 

Vb  S 

BlKs  IZE 

lSo  A 

FI 

7 

DISK 

TEMP7 

ORARY 

AA 

IlRECL 

51  6 

RECFM 

v6S 

3LKS IZE 

25b  a 

FI 

M 

DISK 

TEMPS 

UKARY 

Aa 

ILR ECL 

51  b 

RECFM 

VBS 

BLKS IZE 

25b  A 

*- 

DUNlT  =  1  J 

-LAS  1 

DTYPE  OBJECT  r  1  LB  NAME  1<CR>  IF  NO  MURE  FILES  >? 

DREAD  VARS  DqOJ 
DIF  .  DQBJ  —  «  DOuTO  —DONE 
DONIT  -  6DN1T  +-  1 

FI  DON  I T  UlsK  DU3J  UBJ1750  Aa  ILrcCL  1023  RECFM  VBS  oLKSIZt  SIMA 
DUUTU  -LAB  1 

* 

-DONE 

«*IF  sbDIR  —  ■ 


DTYPE  MSL  «AI  TING  FOR  INPUT 


r  1GG  -  MsGX 


cXEC 


PRlNCtTuN  UNIVERSITY  T  I.ME-SrtAniNG  SY 


*- 

*  M  S  L  X  i_  X  E  C 


gCUNTRUG  cRHUK 
FI  *  CLEAR 

STYPE  LINKAGE  EDITOR  -  M  S  L 

*■  PROOUCcS  4BS  UGU  T  £  FIgE  FRUM  OSJcCT  FILE* 

*  CREATED  1  1  —3—61  8Y  JOHN  RIUhUAN  OF  mIKRuS  SYSTEMS  CbKP. 

*  X  VE RE  1 UN  CREATED 

Ft  t  DISK  St  DIRECT  IV  A.  IRSCF.M.  F  GREGG-  ti.0 

Ft  2"  DISK  SI  MAP  A  ( GRECl.  80  RE€F*t  FBA  BLKSIZE  800 


FI 

FI 

FI 

FI 

FI 

FI 


3-  DISK  S-l  ABS1750  AA 
5  DISK  TEMPS  OK ARY  A4 

o  DISK  TtMPo  OK ARY  A4 

7  DISK.  IEMP7  OkAR Y  A4 

*  DISK  TEMPS  ORArtY  A* 

20  DISK  SI  QBJ17SO  A  A 


(GRECG  1 02  ii  R£  CF*  VBS  BGKSIZE  514* 
(GRECg  SI  o  KfcCFM  MBS  BGKSl/c  itoA 
I  GR  ECU  SI  5  RECFM  VBS  oLKS  1  EE  2SBA 
tGRECU  Sis  RfcCFM  VBS  BGkS  lz£  2WJ4 
(GREGG  51  a  RECFM  V3S  3GKS1ZE  258 A 
(GRECG  1020  WECFM  VBS  BGKSlZfc  51  A* 


.MSG 

* 

wlYPfc  REFURMAX  PROGRAM.  .  -  R  F  M-  T 
*■  CREATES  A  GCaD  MODULE  AND-  A  SYMbOL  TABLE 

*  FRQIM  AN  ABSUGUTi  FILE* 


FI  3  DISK  SI  MOD  1 750  A  < HECFM  Fo  GRECG  bO  jGaSIZE  fcOO 

*  Fl  A  DISK  SI  5YM17SO  A  (  RfcCFM  F  GRfcCL  102*  ouSUE  1024  DSutxG  jA 
FI  a  dummy 

FI  2  DISK  SI  Ad  SI  750  AA  ( RECFM  VBS  uRECL  1028  BLKS1ZE  SlAA 
GOAD  RFMT  ( CGEAS  START 

*  RFMT 

SIF  S  RET  CO  02  >  O  St  A  IT 
ERASE  TEMPS  UWARY  A 
ERASE  TeMPB  UKAkY  A 
ERASE  TEMP  7  OR  ARY  A 
ERASE  TEMPS  ORARY  A 
SEXIT 

* 

-e  HR  CRt 

GlYPG  "  KtUulKED  '*  MtANS  "X  I  TrtUUT  WHICH*  NUT  MING”  J 
STYPE  TRY  AGAIN 
SEXIT  I 
SEXIT 

* 

— E  AH  UR 

STYPE  SURRY*  A^sUgUTE  rlU 
STYPE  GOODBYE*  TRY  AGAIN 
SEXIT 


-* 

I 

•> 

I 

\ 

k 

] 

I 

- 

s 

i 

I 

» 

4 

I 


NAME  Is  kcUUIkED 


rlU£:  MSS 


EXEC 


A 


pkincetun  university  timc-shakino  sy 


EXE 


tCUNTROL  ERROR 
CP  TERMINAL  LiN£5IZE 
U-TyPE  t  750 A  blxULAluft 


SIMULATES  A  1/SOA  MACHINE  RUNNING  The 
PREVIOUSLY  CREATED  LUAU  MODULE  AN  U 


SYMdUL  TAoLi 
CREATED  1 1 -3-d l  SY 
FI  * *•  CLEAR 

FI  5.  TERMINAL  (LksECL  SO 
FI  o  TERMINAL  (lRECl  a0 

fi  a  terminal 

FI  a  OlS*.  PEKHLP  HELP  a 
FI  T  DIS*  PEA  ERR  HELP  A 
FI  10  OISK  TEMPIO  ORaRY 
FI  to  DISK.  T EMP  1 0  ORARY 
FI  II  TERMINAL  luRECL  ao 
FI  20  TERMINATE 
FL  2.1  TER.MI.NAl)  .. 

Ft-  22  Terminal  Rs*' 

FI  23-  TERMINAL^ 

FI  2a  TERMINAL  LI 

fi  ao  tcrmina»T\ 

FI  31  TERMINAL 
FI  32  TERMINAL^ 

FI  33  TERMINAL 
FI  3*  TERMINAET-  C° 


JOHN-  R  IORDAN  OF  MI  XROS  SYSTEMS  COKH* 


tRECFM  Fa  LrtcCL  dO  oLxSI  ZE  uOO 
(HECFM  FU  LRECL  dO  SLKSllE  aoo 
A  (  HECFM  F  LRECL  I  02a  bLKs  IZE  102 A  oSORG  DA 
A  I  a TENT  i 02a 


t*T  yPE  LOAD  M<IuUi_E  FILE  NAM 

DREAD  VARS  dLDm 

OIF  •  t»LD  M  =  •  OGOTO  -ERROR 


NAME  <  KEUUi RED l 1 


*  6.TYPE  SYMuOl  TAdLE  FILE  NAME  l  REQUIRED)? 

*•  OREAD  VARS  ESYM 

*  olF  .osym  =  .  too ru  -error 

* 

OTYPE  SIMULA  Iuk  CuMMAND  FILc.  NAME  l  <C  R  >  IF  TERMINAL  >? 

OREAD  VARS  ODaTa 

*■ 

FI  12  DISK  &LDM  MCi>l  750  A  CRfcCFM  Fb  LRECL  SO  BLKSIZfc  OOO 
OTYPE  LOAu  MOCXJLE  FILE  slQM  MODI  750  ON  UNIT-12 

*  FI  9  DISK  t»S  1 M  dYM  i  750  A  <  RaCFM  F  LRECL  102*  SLKalZt  1024  USiXG  DA 
FI  9  DUMMY 

OTYPE  SYMSUL  TAdLE  FILE  USYM  SYM1750  ON  UNIT  9 

♦ 

GIF  .&DATA  a  .  &GOTO  -CD 

FI  11  DISK  wDAT-t  COMMAND  a  A  (HECFM  F  LncU.  cO 
LTYPE  S1MUL.  COMMAND  FILE  DDATa  COMMANDS  UN  UNIT  II 

m 

— tu 

LOAD  MSSt  MSS2  MSSa  MSS*  MSS  5  MSSd  MS57  I  CLEAR  START 
ERA«»E  TEMPIO  ORARY  A  <  NO  I  YPE 
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l£.s  >«bb 


cX£C 


PulNCtTUN  UN  t  VERil  T  Y  r  lMc~bhA«  I  No  bY 


UEXIT 

,h«Ok 

&TYPE  RhUUlRED  Fll_t  NAME  NU  T  SUPPLIED 
&TYPE  TRY  AoAlN  ✓ 

&EXIT  1 


file:  mssx 


LX  EC 


A 


PK  JNCE fON  UNIVERSITY  TIME-SHARING  bY 


EAEC 


SCUNTRUL  ERHuR 

6TVPE  1 750  A  SIMULATOR  -  M  S  S 

»  SIMULATES  A  l  7S0A  MACHINE  ExeCUT  INu  THE  PREV  luUbLY 

*  CHEATED  LOAD  MODULE  AND  bYMauL  TABLE. 

*  CKcATcD  lL-7-di  dY  JOHN  KluRDAN  UF  MIKRUS  bYbTcMb  CuRP. 

* 

LIF  «Ll  =  •  lGOIQ  -ERROR 
FI  *  CLEAR 
FI  S  TERMINAL 
FL  i  TERMINAL 
FI  6  TERMINAL 

FI  a  DISK.  PeKmLP  HELP  a  IReCFM  Fa  LHcCL  ao  BLKS1ZL  800 
FI  7  DISK  P£K£RR  HElP  A  {RECFM  FE  lRECL  EO  BlKSIZE  aOO 

FI  10  DISK  TEMPI  O  OR  ARY  A  {RECFM  F  LRECL  I  02  A  BLKS  IZE  1024  USORG  DA 
FI  lO  DISK  TEMPlO  QRaRY  A  ( XTENT  102a 
FI  II  DISK  6  1  COMMANDS  A  IR£CFM  F  LRECL  DO 

* 

FI  1C  DISK  LI  MQD1750  A  (RECFM  FB  lRECL  SO  BLKS1ZE  800 

*  GTYPg  LOAD  MODULE  FILE.  61  MODI  760  ON  ONIT-12 

FI  DISK  El  SYM1750  A  {  kECFM  F  LRECL  1G24  BLKSIZE  1024  DSURG  DA 

*  6-TYPE  SYMBOL  TABLE  FIL£  61  STM1750  ON  UNIT  * 

FI  20  TERMINAL 

FI  21  TERMINAL 
FI  22  TERMINAL 
FI  23  TERMINAL 

fi  24  terminal 

FI  30  TERMINAL 
FI  31  TERMINAL 
FI  32  TERMINAL 
FI  3o  TERMINAL 
FI  34  TERMINAL 

* 

LOAD  MSS 1  MSS2  MS S3  M  SS4  MSS 5  MSS6  MSS7  (CLeAR  START 

* 

6EX1T 


-ERROR 

6TYPE  RE uU I RED  F ILE  NAME  NOT  SUPPHEu 
6TYPE  TRY  AGAIN 
6EXLT  I 


FORTRAN  Code  for  Implementation  of 
PI/PO  and  CI/CO  Instructions 
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date. 


}  .0  (Ol  MAY  ati)  SYSTCM/.J70  FORT  Ran  M  ExT-NOED  (ENHANCED) 

>TlUNSi 

;I=KECT:  nmMc.(MA1N>  OPTIMIZZ13)  l_I  RECOUNT!  60  )  SlZE(MAA)  A  oT  UOd  L  C  NO  Nc  ) 

SOURCE  EuCD  IC  NOuIST  NOOECK  OBJECT  NOMAP  NOFORMA  T  GOSTMT  NQXREF  NUAlC 


SJa.ttJUri'le  1MICMD*VAl> 

c - - 

c 

C  PURPOSE:  PERFORM  INPUT  FROM  DEVICES 

c  ax^umen r a:  cmo  —  input  command 

C.  VAU  -  v A LJt  TO  oE  KtCEl^tU  FROM  DEVICE 

c  programmer:;  nc  baker 

C  DATE,  created:  7  JUL  ivso 

C  CHANCE  HISTORY :  *ncn6v 

C  SIDE  EFFECTS  1  ANQME* 

c  remarks:  this  ts  a  stub* 

c  XT  la  beING  F I  CL  tD  IN  bT  G.RIOROAN  Ur 

c  M1XH0S  SYSTEMS  CURP. 

C  1  AM  ASSUMING  QtFUH  Pi  «PU  COMMANDS)  THAT 

C  THE  SECOND  HE*  DIGIT  REFERS  TO  TrE  CHANNEL 

C  NUMBER  (0-3)  -■ 

C  WRITTEN  12-1 3-dl 

C  Calls:  *nune* 


lMFCiGtr  UMTEGERtA.— it 
EXTERNAL,  and *or  .shift. xor 
INTEGER  CMO»VAU 
INTEGER  Hilo) 

INTEofcR 
INTEGER  CS(4I 

DuUttUE.  PRECISION  T  1M  vAG*  T I MRA  T»T  I  MQR 

COMMONyQTIMERyTIMVAUC 3)«T1MRATC3)  •  TIM  DRi  3)  .  TlMFLI  3  )•  TIMFLD13  ) 
CCMMONyQQyi_OP»  RQP»  NBGNXT  *ATYP6  *OPM 

COMM  uN/QSR/yeK TrP *  UCrtP  CB  «  GcR  CL T »  GC «HL T »GcrPk  *  uct<LUP» E  R  kuUC »iiRR  a  PU  * 
-=HHaPT»g  RR  INN.cRRF  PU  .2RRFOU«ERRUPM  ,cR«  ICF  .  ERRUCF  «c  PRINT  »cRrtPKl 
COMMUNAUMK.CY/M  •  IPK  .UPR  *  ROM  »MP«AM 

COMMUNyE  VENTAFuuV  .  GUUG  1 .  FLUV .00002  «FXQV  .00003  *  I  NTRPT  *00004-  .R  TN.UOQ 
—US 

CQMMONyoVALyQV  ALS.OUOOoC  2>  .cC.OEdUG.FT  *MK. Pi  .OS  TINT*  I N TRE N.ROMEN.M 

—  PUN  *  DMA  cN  »  FC  *  |  O  »  IU  II  1ft  111  ICE  *MF  SR  •  DoO  *  D  I W  *  Pud  •  Nt  AT  •  GOM  A  A  «  kO  »  R  1  «  R  c  .  R 

—3  *Ha  ftp  a  »  R  o  *  r7  *  PO  »R  R  A  .RE  *WC  *RF  *C*  P  •  Z  •  N  *RESDftPs«AS  •  DUG  Q  7 1  1  )  * 

—  Al_  •  M  U  *G  UUGo  11)  fuuii  1  )  *  GGgU  10(1)*  RDM  T  UP  •  GOOD  1  1  (  1  )  •  T  IM  ~  R  A  •  T  1  MEK  e • G 
-UftUOASE  ..GLOQP  .FP 1  •  nORMCK  .CuNSOL  .  IMA.  I  QIC  .P  AGES  •  TIMER  S  «  SRUM  .LUCK  EY  » 
—PRO  T  » DM  A  ftO I SCR T.SNFSR.SGO 

COMM ONXD I  AI_QGy  INSTR(  l  1  .  TOS  TOP,  T05N AP *  INTO  .FROM.  INSTEP 
CUM M «JN/ Q UN  lTSAulNU  ftUOU  rUftGLOGUftGSYMU.UDl  SKUftURAMU* 

—  Daau.GPi_4U.GlNPU(  S).GGUTPU<5  » 

CUMMuN  /iOHANOy  IC UR l S )  • OC UR <  b )  » 1 NuUF < b * 30 ) *  OUT bUF ( 5 • a  0 ) 
COMMONyVAl_STKyGVt_SIZ.aVUPTRrQVl.STK  (7. 30) 
cGUl VAUENCECRl l) .RO) 

=OU  i  VALENCE  (  SAM  I  )  •  CSC  1  )  ) 

SUU  1  VALENCE  (Cs  (  I  )  •  C  ) 

=.UU  I  VALlNCcC  R1  0»RA  ) 

EGU  I  VAuENCE  (  HI  1  .Ha  ) 

EGUIVAuENcE(R12.RC  > 

EQU  I  VALSNCcl  R1  P.R O  ) 

EQU  r  VALcNCci  R  1  A  *  RE  ) 
r.'JU  l  VAL.ENUK  (  RI  b.RF  ) 
cGU  I  vALtNCtldMiEu*  hC  ) 
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JATt 


J.O  (01  <IAY  OO  >  IN  3TSTEM/370  FuRTRAN  H  UATENDcU  lliNHANCELtl 

S.OUX  VALtNCc.{  BasE.1  »WO> 

EQU1  VALeNCEldASEa.HE) 
dUUl  VAL£NCS<SAi»EJ*«F> 
lOU  i  VALENCE!  3P  .hF  ) 

INTEGER  HE  AWA  Y  1  A  J  .  N» CHNL NO 
iNTcucM  sk_A>sK 
OAT  A  BLANK  /•  */ 

C  CHNL  NO  =  CHANNEL  NUMBER  10-3) 

C  l^lCUR  a  PROGRAMMED  INPUl  CUNSCH 

c_ 

IF  (  CMO. cU.A41 50)  GO  To  101 

C  PrLLIRAM.MEU  1MPU-T-— _ _ _ 

c  CALL.  HE*  TO  CONVERT^  C.MO-'  Ttt  r»eX  VALUES  TO  PIC*  OUT  CHANNEL.  NO. 

CALL.  MEXLTtCMO.HeXRAT*  i|  - 
CHNL  NO  =  HEASA-Ttil  *■  L 
vAJ  TO  102 

101  CHNlno  =  a. 

102  1FC  t  ICUkiCHMLNul.iUal^ANU.UCUKlCHNLNU)  .cr.dl  1  >  GO  TO  103 
ONI  T  «  Cl  I NPU  (CHNLNO) 

AHtTfctUNlT .10011 

iooi  h‘uNMAii/»»>  consule  input*) 

^cAUtUNlT  *  1002  .END  -M9)  !  INsUKlCHNLNu.N  )  .N  =  l  .oO  ) 

1  0.»2  FUPMAT(dOAl) 

ICVIR.  (CHNLNUL  a,-.-  L .  -  ^ .  . .  _  _  -r 

103  FIRST  *  tCUR(CHNU*Q*##%  r  C 
90  i«  'X -jo 

IF  ( INOUP iOWLNO.N)«eU2)LAMK )  SO  TO  lO 
CALL  LOOKUP! 1N6UFI CHNLNO .n )• VAL • 1 ) 

1 CUKl CHNLNO)  —  N  ♦  1 
pie  torn 
10  CONTINUE 
V9  VAL  a  13 

l  CURi CHNLNO)  *  O 
RETJRN 

c 

-NO 

lFFECTanAMEImAIN)  OPTIMIZEI3)  LX  NECOUNT  (  60  )  SIZE(MaX)  AuTODSl!  NONE  ) 
cFFcCT*SOUHC5  cSCOlC  NOLIST  NOOECX  OBJ EC  f  NOMAP  NUFQRMA r  GQSTMT  nUaREF  NOALC 
*  SuURCE  STATEMENTS  a  txl  »  PROGRAM  S 1 2E  a  7qo,  SUBPROGRAM  NAME  a 

«  NO  ^.1 A  3  03  r  !CS  <jcn£HAT£D 
qF  compilation 


23©<  dTTES  OF  CQm 


DATE 


3.0  10  l  MAY  jO  )  SYSTEM/J70  FORTRAN  H  fcXIENDcD  (ENHANCED) 

pTiuns: 

EFFECT:  uPTIMlifc(J)  u  1  Nt  CuUN  T  (  oO  )  SiZE(MAX)  aUT  CJOBLl  NONE  > 

SOURCE  EBCDIC  NOLlST  NODcCX  OBJECT  MO  MAP  NOFQRMAT  G05TMT  NQXReF  NCALC 


SUBhOuT  1  Nc.  0  JT  (CAD. VAC  ) 


PUKPOSt I 
a  k  Cum  e  n  T  s  : 


hERFORM  OUTPUT  TU  DEVICES 

cml>  -  output  commamd 

VAC  -  VmCJc  to  oE  output 

NC  BAKER 
7  JUC  I960 


phuorammeh:  nc  baker 

date  created :  7  juc  iveo 

CHANCE  rtisTO***:.  *NUN£* 

SIDE  SFFSCTSi  *NUn£P 

remarks:  this  is  a  stub 

IT  IS  being  F I  EC  ED  IN  by  J.  RIUROAN  of 

MIXRuS  SYSTEMS  CuRP.  WRITTEN  lE-lS-Bi 

calls:  awone* 


IMPLICIT  INTEGER! A-Z) 

external  ano.ur.sh IFT.XUR 
INTEGER  CMD.VAL 

INTEGER  RHo)  _ _ ______  _ 

INTEGER  S*UI=  "  " 

integer  esc ♦  i  .''r 

DOUBLE  PRECISION  TIMVAC.TIMHAT. TIMOR 

COMMUN/qT  I  MEH/  TIMVALt  J  ),  T  IMHATI3  I.TIMORC  3)  *T  I  MFC(  3  >  ,  T I  MFCU  (  3  ) 
CUMMQN/’UQ/LUP.RUP.  NnLNXf  ,ATYM£  .UPM 

COMMUN/UbR/UCR  IRP»  uE.-F  Cb  «  0£  RCL  I  .UcRHL  T  .utRPK  .  ufcRLDP,  ERRUuC  .cRkxpu. 
-cRRBPT.ERR  INN.ERRFPU  «t RRFPU.EfiftQPM  .ERR  ICF, ERROCF .ERR  INT.cRRPR  1 
COMMON/OMKEf  /M  •  I  PR  .OPR  .ROM  .HpRAl* 

COMMON/ EVE NT/F CO V.  Ouud  I  .  FLO V  *00002  iFXUV  .00003  .  I  NTHPT  .OQOOA.R  IN.GUUl 


COMM  UN/ U  V  Al_/0v  ALS.  ovuud  <  2  )  .  EC.  U£uUw,F  T  .MK  .Pi  •  LS  TImT.  1NTREn»RumCn».m< 
-«EN  .UMAEN.FC.  IC. 10  1C  1,10  ICE. MFSR  •  OUB »  D  l*  »POb  .N&xT,  uOMAX  .kO  .«  I  .«i.  R. 
■3 .HA  .MS  *Ho  mV7.Rb.RV.KA  .RB.RC  .RO.RE  *RF  »C.  P.  Z.N.  kESO  .PS*  AS.GQQQ71  I  >  •• 
-Mt-.MU.OQGGBC  II  .00009(1  )  .GOQGIO ( 1 > • ROM TOP .GGOG H  (  I  1  .TIM  ERA.  TIMEko.G. 
-Q.UU  aSE  .OLCOP.FPI  •  NORM  CX  .CONSOL.  IMA.  I  UiC.PAuES  .TIMERS  .  SROM  .LOCK  cY  •• 
-PRO  T  .OMA.O  I  SCR  T.SMFSR.SGO 

CUMMON/DIAlOG/INST  r»(  i)  .TOSTUP.  TOSNAP,  I  Ntu  .F  rUM  .  INSTEP 
cummun/vaun  i  ts/ginu  .ocutu.gldgu  .gsymu.  odisku.oaamu. 

-  OuGU.UPlTu.OINPUC B) .00UTPU(5> 

COMMON  / IOHANO/  ICuR IS  > *UCUH t  S  )  »  1 NBUF ( 5.B0  >  * UUTBUF ( S .BO  I 
COMMUn/V  ALSTK/OVLSIZ.OVLPTR.OVLSTKt  7*  B0> 

3001  VALENCE C  Rl  1 )  HO  > 

EuU  1  v  AC  t  NC  E  (  S<*  (  i  >  «  CS  (  1  >  > 

SOU  I VALcNCE ICS ( 1 )  .  C 1 
EOUI VAuENCCt RIO.RAI 
EuUI  VAucNCECHll.RQ  > 

EUUI valencbirie.hc  > 
cOU I VALENCE! R13. HO ) 

ECU  I  VAC  EnCEI  Rl  a  .  RE  ) 

=.OU  I  VALENCb!  Rl  5.HF  1 
SOU  I  VALENCE!  BAsEO.  RC  » 

EQU l VALENCE (BASE l . HD  I 
SOU i VALENCE ( BASES. RE  1 
EOUI  VALENCE!  BASES.  aF) 
iUUl VALENCE! SP.hK) 
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3. U  to  1  MAY  dOl  UoT  aVSTcM/37a  FuMTMAn  rt  EXTENDED  (.ENHANCED)  OaTE 

INTEGER  hEaRAY  (A).  N«CHNLNO 
INTEGER  dLANK 
DATA  dLANK/*  •/ 

C  * 

IFluMO.  cu.  Io3Ua)  Tu  101 

CAUL  hcxl TtCMU.rfciXKAY) 

C!-F4LNU  —  rlEArtArtj)  +■  1 
oO  TO  102 
l  IU  CHNLNO  a  S 

4  02  Ir'l  l  V  AL  •  NE* l 3 )  •  AND  •  (  UCVJN  (  CnMLNO  1  .GT.O  > 

-  .  Anl).(  OCJR  (CHNLNU)  .Lt.SU  »>  uU  ro  <* 

UNI  r  a-  LUU-tFU(CHNLNUl- -  -  —  - 

wR  I T  £  { U  N  i  T  « I  QOl  UQ  UTBU  FtCHNLNO  .Nl«N*l.oO> 
lOOl  FURmA  ft  3QA 11  -  _ 

VAL  a  O 

CCUK (CHNLNU)  *  1 
UO  7  I  a  1  teU 

l  (JUT EOF  C  CHNLNU. »L  1  a  BLANK 

RETURN 

V  CALL  LUUKUP(OUTtHJIs(CMNLNO»QCUH(Ct-»<LNU>>»VAL»2> 

OCUW (CHNLNU)  a  (JCUKt  CHNLNU  1  ♦  1 
ri£TU  ."IN 

End 

cFrtCT*NA4(tUAW).  OPTiMlZEUiLLiNteCLUN-I  Cdtti-  SIZE  (MAX.)  AuTQDBLC  NONE). 

EFFECT  *SOUftC&  EBCDIC  NQLtST  MODECKr  OBJECT  NGMAR  NOFORMAT  CO  STMT  NOXREF  NOALC 

*  SOURCE  STATEMENTS  »■  S5-«-  PROGRAM-  SIZE  a  S7A*  SUBPROGRAM  NAME  = 

*  NO  Dl AGNOSTICS  GENERATED 

OF  C0M°1LATiGN  ******  2AOK  BYTES  OF  COM 


524 


uoTt 


3.0  101  MAY  aO )  ^fbruM/jt70  FORTRAN  H  tXT  tNu&U  (£NHaNCcO  ) 

pTiuns: 

EFFECT  :  mAM  fc  (  MAIM)  UPT1M1ZL(3>  LlNeCOONTC oO >  bIZEI  MAX)  AUT0DaL(  NONE  ) 
v  SOURCE  EBCDIC  N0l_l5T  NODECK  OBJECT  NOMAP  NGFORMA  T  CiOS  TM  T  MOXHcF  NuALC 

C 

jUO.tUjriNt  HCA  l  rco  LLNUM  >  AkRA  Y ) 

c  this  routine  produces  a  pseudu-hex  array  for  a  decimal 

C  InPuT  VAuUE.  Fuft  t X A MP LE  •  Trie  OECIMAL  VaLJc  1033*  XHlCrt 

C  In  Hex  la  3Fr  IS  PRODUCED  AS  **3  15  Is**  BUT  IN  REVERSE 

C  ORucR  C  IE*  array  (  1  >=l5,ARR«r  l<>  >-lt>.AkRAY  t3)®3.  ANO 

C  ARRAY |M»®0 ) • 

INTEGER  DECNUm.aKRAYIm) .NUMB .1 .LSTNUM 

c  the  input  value  decnum  not  altered. 

C  A  COPY  IS  MADE  TO  ISOLATE  IT . 

wSTNuM  =  DECNUM 
numb  »  lSTnum 
DO  lO  1  *  l»A 

NUMB  s  NUMB/  l  C» 

ARRA  Yt  1  )  a  LSTNUM  —  Cl5*NuMB> 

10  LSTNUM  a  NUMB 
RETURN 
EnO 

£FFLCT*NAME(MAlN)  UPT1M1ZEC3I  LlN£C0UNT(60>  SIZE (max)  AUTODdLt NuNE ) 
EFPECTdSUURCS.  EBCDIC  MO  LIST  nQOEOC  OBJECT  NOMAP  NQFQRMA  T  GOSTMT  NGXREF  NOALC 
*■  SOURCE  STATEMENTS  a  to.  PROGRAM  SIZE  a  302.  SUBPROGRAM  NAME  = 

*  NO  DIAGNOSTICS  GENERATED- 
OF  COMPILATION  ♦**«** 


252K  jYTES  OF  COk 


r 


*  v  •  -■ 


B 


J  101  MAY  sO  X  3f3TEM./370  FORTRAN  H  fcXTcNOED  (EJVRANCED)  OATb 

JTlGNSi 

•FFECT  S  NAMEIMAIN)  OPTIMIZE!  3)  UNECQLKITC  f»Q  )  SIZE  (MAX  )  AUT QOQL.C  NONE  ) 

SOURCE  EBCDIC  NQL  1ST  NUUECK  UBJECT  NOMAP  NUFOWMAT  GuSTMT  NUXReF  NuALL 


C 

C 

c 

c 

c 


SOdfUAfTlNK  UUuKUPl  CuAN  *NUMo*AMICH) 

this  routine  searches  one  table  fur  mt  input  value 

ANO  RETURNS  ITS  ASSOCIATED  VALUE*  IF  »H l Lrt  =  I.  THEN  THE 
THfc  TRANSFORM  Is  char  >  hex;  IF  «HICH  =  2.  THE  TkANsFuRa 

is  «ix  >  char*  defaults  are  returned  if  no  match  is  found. 

INTEGER  TASLEAt  6A-)  *-TA*JL£3C  3A-)  .  INDEX  .CHAP  »NUM3  »*HICH 
DATA  TABLE*  /r  r*» 


•  •&•»•/•••«••  »9«  « 


»**,»-*. 

•  ;•••  ;••»<» ••=•••>•••?•. »r» . 

•a*  ^•s»*,C-,*,d«%»e,*.,f»^»g**»h»  »  •  i •  a  •  l  •  •  *m •  • 

•N*»*0*.  •P*»*Q*r*R***S,««T»*,U,*,V,»,M,*,X,*,V,*l>Z** 
*-•»  »*s  ►=•»  »?  •  r 
DO  d  INDEX  s  I *o3 

tad llp i index)  *  index  +  3 1 

CUNT  INUE 

TAoLaUBAL  a  4*t  ^r.  ., 


c 

c 


IF  twnlCH«Ea«2*  GO-  TOE  2<*‘ 

CHAR  >  HEX  (  INPUT) 

DO  10  Ino£x  *  1,04 
IF  ICHah^E.TriLcaI  iNOfcXJ  1  GO  Tu  10 


a 

NUMo  *  TA3LE3I  INOEX) 

RE  T  URN 

io 

CUNT INUE 

yl 

NUM0  ®  - 1 

M 

RETURN 

>*w 
•v"  * 

c 

c 

he  a  >  CHAR  t OUTPUT) 

01 

20 

DO  30  INDEX  %  I .SR- 

■ 

r.  ' 

r 

IF  (NUMS*NE»  TABLE  31  INDEX)  )  GD  TO  SO 

CHAR  *  TaSLEAI  INDEX) 

RE  Turn 

r  *- 

jU 

CUNT  INUE 

r. 

c 

NOTE;  TAOLSA132)  =  »7*  OEFaUUT  VALUE 

• 

CHAR  »  TAULEAtSZ) 

r 

RETURN 

END 

I 

J 

ErFiCT*NAMElMA  IN)  QPTIM1ZE13)  lI  nECUUN  T<  60  )  SIZEtMAX)  AutuDoLl  NONE  ) 
EFF£CT*SOukCE  EiiCOlC.  NOcist  NUOfcLA  ubJECT  NUMAP  NQFOkMA  T  GUSTmT  NuaREF  NdALL 

*  SOURCE  STATEMENTS  —  26*  PROGRAM-  SIZE  *  1012.  S  US  PROGRAM  NAME  =l 

*  NU  DIAGNOSTICS  GENERATED 


JF  COMMIlATIUN  ****** 

*  NU  Ul AGNUS i ICS  THIS  STEP 
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THE  AFWAL  MIL-STD-1589B  JOVIAL  J73  COMPILER 


Mike  Burlakoff 

Support  Systems  Branch,  AFWAL/AAAF 
Wright-Patterson  Air  Force  Base,  Ohio  45433 


Introduction 


The  Air  Force  Wright  Aeronautical  Laboratories  (AFWAL)  JOVIAL  J73  compiler 
was  developed  for  the  Avionics  Laboratory  by  Software  Engineering  Associates. 
This  compiler  was  developed  by  modifying  an  existing  JOVIAL  J73/I  compiler  to 
first  compile  MIL-STD-1589A  code,  and  then  upgraded  to  MIL- STD- 1 589 B.  The 
compiler  was  re-hosted  from  the  AFWAL  DEC-10  to  the  Aeronautical  Systems 
Division  (ASD)  IBM  370  computer.  During  the  development  process,  MIL- STD-1750 
and  MIL-STD-1750A  code  generators  were  developed.  The  source  code  of  the  com¬ 
pilers  has  recently  been  translated  from  J73/I  to  J73  for  both  hosts  and  all 
targets . 

History  of  the  Development 

Between  1974  and  1976,  an  Air  Force  project  was  initiated  to  develop  a 
JOVIAL  compiler  for  the  Avionics  Laboratory  Digital  Avionics  Information  Sys¬ 
tem  (DAIS)  program.  The  contractor  for  this  effort  was  Computer  Sciences 
Corporation  (CSC)  and  the  compiler  developed  was  a  JOVIAL  J73  level  I  or  J73/I 
compiler. 

The  techniques  used  to  develop  the  J73/I  compiler  were  as  follows:  1)  A 
compiler  was  written  in  1108  assembly  language,  and  hosted  on  a  UNIVAC  1108 
computer,  to  compile  JOVIAL  J73/S  code  which  is  a  subset  of  JOVIAL  J73/I; 

2)  The  compiler  source  code  was  then  written  in  J73/S  and  compiled  with  the 
original  1108  assembly  language  version;  3)  A  code  generator  was  developed  on 
the  UNIVAC  1108  machine  to  produce  code  for  the  DECsystem-10.  This  began  the 
retargeting  and  re-hosting  process;  4)  The  compiler  was  then  re-hosted  from 
the  UNIVAC  1108  to  the  DECsystem-10  and  upgraded  to  the  JOVIAL  J73/I  language. 
The  compiler  source  was  then  written  in  J73/I;  5)  Code  generators  were  then 
added  for  the  AN/AYK-15  and  DELC0  M362F  computers.  The  AN/AYK-15  computer  is 
considered  the  predecessor  to  the  MIL-STD-1750  computer  and  is  sometimes 
referred  to  as  the  Hot  Bench  Computer  (HBC). 

J73/I  Applications 

With  the  J73/I  compiler  now  hosted  on  and  targeted  for  the  DECsystem-10 
and  also  targeted  for  the  AN/AYK-15  computer,  the  compiler  received  a  great 
deal  of  use  in  large  scale  avionics  support  software  systems  and  in  Avionics 
Executive  and  Mission  Software  systems  using  MIL-STD-1553A/B  protocol.  This 
extensive  use  of  the  J73/I  compiler  for  developing  code  on  a  large  host  and 
executing  on  both  the  host  and  avionics  (AN/AYK-15)  processors  resulted  in  a 
very  mature  compiler.  The  compiler  was  also  used  by  a  number  of  other  organ¬ 
izations  and  was  the  tool  used  for  the  J0CIT  compiler  development  effort. 


MIL-STD-1589B  Development 


Between  1979  and  1980,  Software  Engineering  Associates  (SEA)  of  Torrance, 
California  developed  the  MIL-STD-1589B  version  of  the  compiler  for  the  AFWAL 
Support  Software  Group  of  the  System  Avionics  Division.  Gil  Weisbord  and 
Mike  Littlejohn  of  SEA  were  the  principal  developers.  Bob  Engimann  of  TRW 
has  been  performing  integration,  problem  analysis  and  configuration  control 
of  the  compilers. 

The  techniques  employed  to  accomplish  this  MIL-STD-1589B  development 
were:  1)  Modify  the  J73/I  compiler  to  compile  JOVIAL  J73  (MIL-STD-1589A) 
programs  on  the  DECsystem-10;  2)  Add  code  generators  for  the  MIL-STD-1750 
and  MIL-STD-1750A  hardware;  3)  Re-host  from  the  DECsystem-10  to  an  IBM  370 
with  IBM,  1750,  1750A  code  generators,  and  4)  Upgrade  the  MIL-STD-1589A 
compiler  to  the  MIL-STD-1589B  version. 

The  IBM  370  re-host  was  done  by  AFWAL  at  the  request  of  RADC  to  serve 
as  an  interim  or  backup  compiler  to  the  RADC  contracted  JOCIT  effort.  The 
IBM  re-host  retained  the  same  high  level  of  efficiency  and  maturity  as  the 
DEC-10  version. 

J73  Applications 

The  JOVIAL  J73  compiler  is  presently  being  used  in  the  Avionics  Labora¬ 
tory  by  the  System  Integration  Branch,  AAAS  (formerly  known  as  DAIS).  It  is 
being  used  in  converting  support  software,  the  Avionics  Executive 
and  Mission  Software,  from  JOVIAL  J73/I  to  JOVIAL  J73  on  the  DECsystem-10 
and  1750  hardware.  The  compiler  has  also  been  used  in  a  number  of  other 
Avionics  Laboratory  software  development  projects  such  as  development  of  the 
ALINKS  1750A  Linker  (TRW)  and  che  JOVIAL  Interactive  Debugger  (TRW). 

Other  Air  Force  agencies  have  used  the  compiler  to  develop  software  sys¬ 
tems  such  as  the  Programming  Support  Library,  Code  Auditor  and  the  JOVIAL 
Automatic  Verification  System. 

The  Avionics  Laboratory  has  distributed  the  compiler  to  approximately  63 
outside  agencies.  It  is  currently  being  used  throughout  DOD  by  developers 
of  JOVIAL  software.  Some  of  the  larger  Air  Force  programs  using  the  compiler 
are  LANTIRN,  F-16  and  the  KC-135  Update  Program. 

This  product  is  currently  the  only  available  MIL-STD-1589B  JOVIAL  com¬ 
piler  and  is  being  used  as  a  baseline  for  a  number  of  other  JOVIAL  compiler/ 
code  generator  developments.  Code  generators  for  the  ZS0002,  TI990  and 
TI9900  series  have  been  developed  and  the  INTEL  8086/8087  Code  Generator 
(IBM  370  host)  is  being  developed  using  this  compiler.  The  J73  compiler  is 
also  being  re-hosted  on  a  VAX  11/780  by  che  Embedded  Computer  Standardization 
Program  Office  (ECSPO).  Because  of  its  wide  distribution  and  use,  it  is 
expected  that  other  developments  will  evolve  from  this  baseline. 


Compiler  Hosts/Targets/Features 


The  compiler  is  hosted  on  the  DECsystem-10  and  targeted  for  the  DEC-10, 
MIL-STD-1750,  MIL- STD- 175 OA,  AN/AYK-15,  and  the  DELCO  M362F  MAGIC  computer. 
The  average  CPU  memory  required  on  the  DEC-10  for  the  compiler  is  approxi¬ 
mately  75K  words  and  the  average  compilation  speed  is  approximately  2400 
lines /minute  and  1100  statements /minute. 

The  other  host  is  the  IBM  370  system.  It  is  targeted  for  the  IBM  370, 
MIL-STD-1750  and  MIL-STD-1750A  hardware.  The  average  CPU  memory  required  on 
the  IBM  370  is  approximately  500K  bytes  and  the  average  compilation  speed  is 
approximately  2100  lines/minute  and  1000  s tatements /minute . 

Compiler  Inputs 

The  compiler  supports  multiple  C0MP00L  input  files  as  defined  by  the 
language  specification. 

The  compiler  supports  multiple  COPY  files  under  the  DEC-10  operating 
system  and  the  IBM  operating  system. 

The  compiler  processes  multiple  source  programs  with  a  single  compiler 
invocation.  For  each  input  source  program,  a  separate  object  module  is 
produced. 

Compiler  Outputs 

The  compiler  produces  object  modules  in  the  formats  defined  by  the 
DEC-10  operating  system,  the  DEC-10  JOVIAL  Interactive  Debugger  (JID) ,  the 
IBM  370  operating  system,  the  AN/AYK-15,  DELCO  M362F,  1750  and  1750A  linkage 
editors.  On  option,  (grammar  checking  mode),  the  object  module  is  not  pro¬ 
duced  . 

For  a  COMPOOL  compilation,  the  compiler  produces  a  COMPOOL  output  file 
in  a  format  suitable  for  subsequent  use  by  the  compiler  as  a  COMPOOL  input 
file. 

All  compiler  listable  outputs  include  on  each  page  the  version  number  of 
the  compiler,  the  time  and  date  of  compilation,  and  the  page  number. 

The  compiler  produces  a  source  program  listing  interspersed  with  diagnos¬ 
tic  messages  for  errors  discovered  during  the  compilation.  A  narrative  of 
the  error  is  given  along  with  the  severity  level,  error  number,  and  point  of 
occurrence.  Each  line  of  the  source  program  has  appended  to  it  in  the  source 
listing,  the  statement  number  of  the  lowest  numbered  statement  which  appears 
on  the  line.  Statement  numbering  beings  at  1.  Statements  are  delimited  by 
semicolon  and  END. 

The  source  listing  can  be  printed  in  well  structured  form  with  statements 
that  appear  at  the  same  BEGIN  END  level  starting  In  the  same  column  in  the 
listing. 


■  The  compiler  can  produce  an  edited  object  code  listing  containing  both 
octal  (or  hex,  if  applicable)  and  symbolic  form  for  each  machine  language 
instruction  produced.  The  first  instruction  produced  for  a  statement  includes 
in  the  object  code  listing  the  source  program  statement  number  from  which  the 
instruction  was  produced.  For  the  IBM  370,  an  option  exists  to  provide  an 
assembly  module  which  can  actually  be  assembled  by  the  IBM  assembler  to  pro¬ 
duce  relocatable  object  code,  which  can  be  linked  and  executed. 

The  compiler  produces  a  set/used  listing  containing  an  entry  for  each 
name  referred  to  in  the  program.  Entries  are  sorted  by  name.  Printed  with 
each  name  is  the  following: 

1.  An  indication  of  the  type  of  the  named  entry  (e.g.,  label,  table) 

2.  An  indication  of  the  scope  of  definition  of  the  named  entity 

3.  The  relative  location  assigned  to  the  named  entity  by  the  compiler 

4.  The  arithmetic  type  (e.g.,  integer,  character)  of  the  named  entity, 
if  applicable. 

5.  The  bit  displacement  within  a  word  of  the  named  entity,  if  applicable 

6.  The  si2e  of  the  named  entity,  if  applicable 

7.  The  sequence  number  of  the  source  statement  in  which  the  named 
entity  is  declared 

8.  The  number  of  each  statement  which  refers  to  the  named  entity 

9.  For  references  to  variables,  an  indication  that  the  variables  are 
set  or  used 

A  source  program  statistics  sumoary  can  be  produced.  The  statistics 
summary  includes  the  number  of  occurrences  in  the  source  program  of  the  fol¬ 
lowing  language  forms:  Characters,  lines,  symbols,  declarations  (by  declar¬ 
ation  type),  statements  (by  statement  type),  and  comments. 

The  DEC-10  hosted  compiler  produces  a  JOVIAL  Interactive  Debugger  Symbol 
Table,  Name  Table,  Breakpoint  Space  and  other  software  features  needed  by  the 
JOVIAL  Interactive  Debugger  (JID) .  (See  Oct  81  Newsletter).  JID  provides  a 
capability  for  debugging  at  the  JOVIAL  high  order  language  level.  JID  is 
available  for  the  DEC-10  host  and  target  only. 

Current  Status  and  Future  Plans 


The  MIL-STD-1589B  versions  (J73/I  source)  have  been  formally  validated 
on  both  the  DEC-10  and  IBM  370  hosts  for  all  targets. 

The  source  code  for  the  DEC-10  hosted  compiler  with  DEC,  1750,  1750A  and 
AN/AYK-15  code  generators  has  been  translated  from  J73/I  to  J73.  An  initial 


version  of  this  compiler  has  been  released  to  ASD/AXS.  The  compiler  and  all 
code  generators  have  been  formally  validated  by  the  Language  Control  Facility. 

The  IBM  hosted  compiler  with  IBM,  1750  and  1750A  code  generators  has  also 
been  translated  from  J73/I  to  J73.  Final  integration  and  testing  was  completed 
in  Apr  82. 

Distribution  of  the  compilers  has  been  transitioned  from  AFWAL/AAAF  to  the 
Aeronautical  Systems  Division,  ECSPO  (ASD/AXS) .  ASD/AXS  will  also  assume  con¬ 
figuration  control  and  maintenance  of  the  compilers  from  AFWAL/AAAF  in 
mid-FY82.  Further  information  regarding  configuration  management  planning, 
problem  reporting  and  compiler  enhancements  can  be  obtained  by  contacting 
ASD/AXS. 
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AFWAL  MIL— STD  1589B  JOVIAL  J73  COMPILER 


•  THEREFORE,  A  MATURE  COMPILER  WITH  CODE  DEVELOPED  ON  A  LARGE  HOST, 

I 

AND  EXECUTED  ON  HOST  AND  AVIONICS  PROCESSORS 


AFWAL  MIL— STD  1589B  JOVIAL  J73  COMPILER 
EVOLUTION  OF  THE  COMPILER  (CONT) 


4)  UPGRADE  FROM  MIL-STD1589A  TO  M1L-STD1589B. 


AFWAL  MIL— STD  1589B  JOVIAL  J73  COMPILER 


IBM  AND  DEC-10  COMPILERS  DISTRIBUTED  BY  AFWAL  TO  APPROXIMATELY  63  USERS 


AFWAL  MIL-STD  1589B  JOVIAL  J73  COMPILER 
OPERATING  STRUCTURE 


AFWAL  MIL— STD1 589B  JOVIAL  J73  COMPILER 
HOSTS/TARGETS/FEATURES 


1000  STATEMENTS/MINUTE 


AFWAL  MIL-STO  1589B  JOVIAL  J73  COMPILER 


CONFIGURATION  CONTROL,  MAINTENANCE,  ENHANCEMENTS, 
AND  SOFTWARE  DISTRIBUTION  TRANSITIONED  TO  ECSPO 


END 
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